Re: [xml-dev] A multi-step approach on defining object-oriented natureof DOM

[Tim Bray <tbray@textuality.com>]

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