Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE:Namespaces are flawed
 Michael Kay wrote: >> This is the second time in this thread I've seen it written that >> Namespaces are flawed. > > > It used to be a permathread on this list, but everyone's given up moaning > except when they discover some new implication. > > The biggest problem is that the spec tries to make prefixes non-significant > and fails. I'll see that and raise you default namespaces. > Another problem is that the spec is vague as to what constitutes a valid > namespace URI (and whether it is ever meaningful to dereference a namespace > URI, resolve it against another URI, etc) This goes back to an issues with specs/stands/reccs. Nobody's talked about implicitness v explicitness in specifications. Implicitness fails us I think. There's a correlation between bozo technology and implicit or axiomatic approaches to specification. Personally speaking, I think I have wasted a lot of time since coming into this industry in having to decipher the consequences of specs or interpret things through to some form of conclusion that may or may not be what was expected. And then to go back to the source or the community only to be told that's not the preferred interpretation. And then watch the bugs and interop reports come in. At that point the typical response is that it that it's too late to fix now. When I think of a spec written in implicit form I tend to think of XML Namespaces. Being able to reason conveniently about the consequences is a useful operational definition of simplicity. Implicitness gets in the way of that by leaving to much to the imagination. XML namespaces is quite short, yet it's difficult to reason about because so much is left unsaid. I think a number of the specs layered onto XML that people see as "small" fit into this category - xml:base and xml:id come to mind. You can look at how people use words as a leading indicator of implicit specification. My working trigger terms for this are "implementation detail", "implementors guide"* and "best practice". They suggest what I would call design smells in specifications insofar as they're claims worth pushing back on and probing further. Unless you've got the guide, the practice, or the code handy of course. The math always gets done. If you can't or won't do basic logical implication you will end up outsourcing the formal analysis to tools developers, who are obliged take an empirical approach to see how the spec's theories stand up. If that's your approach then I think you should outsource early and often :) In terms of supposed simple mechanisms in the XML canon, defaulting and inclusion are the ones I would call out as problematic as they seems endless in their ability to surprise and confuse. Here are some off the the top of my head: xml:base, default namespaces, c14n, derivation by restriction, imports, xml:id, qnames, xml in xml, xinclude. inheritence of feed level metadata to entries. I claim the problem in each case is that the spec writers didn't stress out the logic of their specifications and thus didn't pick up on the implications. These mechanisms were probably specified implicitly and left at that. > The root cause of the problem is that the layering is wrong: naming is > fundamental to XML, and you can't add something fundamental as an optional > layer on top of the core. At any rate, you shouldn't. +1. That namespaces have no syntactic form is the first clue something is awry. And the way XML namespaces went about this (macro expansion) is misguided imo. cheers Bill 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
