Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: A multi-step approach on defining object-oriented natureof
 Amelia A Lewis wrote: > If I interpret this correctly, it is a challenge to give real-life > examples of difficulties, on the part of developers, in dealing with > namespaces. Thanks Amy. This is more useful than the previous 875 posts comprising mostly metaphysical whining. > 1. Carefully constructed code, complete with a comment that the "bug has > been reported to the Xerces team with no response", to "fix" the > assignment of names of unqualified attributes by Xerces. The author was > so convinced that unqualified attribute names needed to be coerced into > the default namespace that he wrote some quite nice code that does so. I'm on the developer's side. Looking back, the namespace of unqualified attributes is just a goof in the namespaces REC. I wonder if there's any chance of fixing it? > 2. API users who have written schemas using the usual defaults > (elementFormDefault qualified, attributeFormDefault unqualified) get > into a fidget when their instances don't validate (because they assign > namespace-qualified names to attributes, instead of unqualified ones). This is because in this area XML Schema is unqualifiedly B.A.D. (broken as designed). > 3. API users who have generated schemas with attributeFormDefault > qualified. Testing with namespaced attributes works great, but when > they try to "simplify the serialization" by using the default namespace, > everything breaks. This time it's because the namespace isn't declared, > and trying to explain that elements can be unqualified and in a > namespace, but attributes can't, is a somewhat painful exercise. Really a combination of #1 and #2. > 4. Namespace mangling due to the ability to define an attribute in DOM > which, on serialization, turns into a namespace declaration. Yeah, Mike Champion has addressed this. I'm not convinced that un-scoping namespaces would really make the problem go away, and the scoping has some pretty important advantages. If you look at any of the alternatives that were proposed for doing namespacing, I think they would have each led to API corner-cases; I don't see any way to achieve the effect (insert syntax in the XML document to make names globally unique) that doesn't pose interesting API problems. I have a good solution but it's probably not generally applicable - I interchange information with XML but I usually mash it as quickly as possible into application native data structures, which have their own APIs aimed at their own needs. I have no problem saying in public that XML is really really good for interchange and really really irritating for in-memory manipulation. I think we all ought to be more up-front about this. > 5. Lots of irritation that the namespace URI isn't the location of the > schema, and that schemaLocation and friends aren't reliable. Is that a > namespace issue? It's a symptom of a weird problem that the markup community has suffered from way back into the SGML days - the irrational belief that schemas are somehow magic, that when you've designed a schema you've designed a language, and that schemas somehow have semantic import. This problem is still rife over at the W3C, as witness the people who insist on wiring schema dependencies into XQuery and the like. I've been ranting about this for a decade but it doesn't seem to do much good. > 6. Several instances of the use of java.net.URL for normalization of a > namespace URI that breaks comparability. This leads to explanations > that "a namespace URI is *not* a [java.net.]URL!" Ouch. Actually the problem is that a URI is not a URL. Application of java.net.URL is going to break lots of different kinds of, for example, URNs. This is actually worse than you think, since there's a community of Windows-centric programmers who just *know* that example.com/foo.html and example.com/Foo.html are the same thing (which in fact they usually are on Windows). I would have supported limiting namespace names to URLs and still would, but it's hard to fight the IETF on this one. There's no currently-valid RFC that normatively defines the term URL. > 7. One rather embarrassing attempt to assign the default namespace to > the URI of the namespaces rec. This was because the person didn't think > that they could use the xmlns prefix without declaring it, so they tried > to declare it, which instead put all of the elements into the XML > Namespaces namespace, which got really surreal. Major ha-ha, and the > developer was perfectly willing to be corrected, but a rather suggestive > sort of error (this was a developer a little more willing to incorporate > XML, who got just enough knowledge to be dangerous). I suspect that 5 different XML implementations would fall over spectacularly in 5 different ways, all confusing. -Tim 
|
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
|
|||||||||
