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-orientednature of
 On Tue, 2002-08-20 at 20:23, Dare Obasanjo wrote: > The fact that namespace declarations and in-scope namespaces are treated > differently in various W3C specs is something I am familiar with and > have written about[0]. However this is not something that is equates to > DIFFICULTY in dealing with namespaces given that Joe Blow developer > doesn't spend his time reading W3C specs. I read on average 10 - 20 > posts a day on our XML related newsgroups and when I hear about > DIFFICULTY with namespaces it typically takes two flavors of questions 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. All right. Some background: I work for a corp (no, not Talsever) that does a great deal of B2B and EAI stuff. The corp is moving toward XML as data representation (customer demand, largely), and so purchased the company I hired into, a little XML startup. Lots of serious XML expertise here; lots of serious enterprise expertise (and close attention to performance issues) in the parent. I get called upon to straighten things out when someone, probably very sharp, possibly antipathetic towards XML (the usual performance anxieties) gets into a bind with our APIs and toolchain, or public APIs that we recommend. 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. Software that uses this code tends to behave peculiarly, to say the least (it's fine as long as there is no default namespace; then the attributes stay unqualified (the comment says this part is still "to do", fortunately)). Encountered once, but interesting evidence of powerful convictions of how namespaces "ought to work" by a very competent (but not highly XML skilled) developer. 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). In one of the three occasions that I recall, the developer became increasingly hostile to discussion of the behavior of attributes, leading to: 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. Tow occasions, one of them a direct result of revision of schema due to item #2; after that a different developer was given responsibility for the XML problem and the first became a general opponent XML for any use. 4. Namespace mangling due to the ability to define an attribute in DOM which, on serialization, turns into a namespace declaration. I forget how many times I've dealt with this one, at least five; sometimes it's done on purpose by one developer (as a hack to attach a namespace declaration, by adding the attribute and forcing a reparse) and broken by a maintainer (who wants to improve performance by removing the "redundant" parse). 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? 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!" 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). *sigh* I envy the folks who get to give presentations, instead of doing crisis management/problem resolution. Items two through four I've encountered often enough to think of them as problems, but documenting stuff only helps when folks read the docco. Five is cataloging, six is related to the fact that namespaces are case-sensitive strings rather than URLs, and seven is more of a giggle than a problem. Does that help any? Amy! -- Amelia A. Lewis amyzing@t... alicorn@m... You like the taste of danger, it shines like sugar on your lips, and you like to stand in the line of fire just to show you can shoot straight from your hip. There must be a 1000 things you would die for; I can hardly think of two. -- Emily Saliers 
|
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
|
|||||||||
