RE: Namespaces, schemas, Simon's filters.

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Ronald Bourret [mailto:rpbourret@rpbourret.com]

<snip/>

> For me, the difference was that I was absolutely convinced of the
> necessity for namespaces, while I'm not convinced of the necessity of
> the "new namespaces" imposed by local element types. In some 
> ways, this
> is odd, as the work I do (mapping databases to DTDs) could 
> benefit from
> them.

I'm just catching up on this thread, now, and I have to say it has been
enlightening. Upon reviewing the insightful comments on this thread -- and
re-reading the namespaces spec to see for myself that local element types do
indeed contradict that spec (although it only contradicts one phrase in the
spec) -- I am myself now questioning the necessity of local element types. I
agree with your sentiments; I think namespaces are a necessity. However, I
am also gravitating toward the far simpler treatment of names that the
namespaces spec gives us versus that of XML Schema. Yes, one can argue there
is utility to local elements, but does that utility justify the extra
complexity and the contradictions between W3C specs it has introduced? I
can't think of a single use case offhand that doesn't simply boil down to a
desire for a bit of syntactic sugar or wanting to reuse brief tag names. Is
this really warranted?

> One other question: when the namespaces spec came out, it was
> immediately obvious to me what was broken and how to fix it. Does
> anybody have a clear idea of what things local element types 
> "break" and
> how to fix them?

Not directly. But I think it is interesting to consider Rick Jelliffe's
analysis of the motivation behind this
(http://lists.xml.org/archives/xml-dev/200108/msg00842.html). The
anti-attribute bias of XML Schema did pose problems for us. We have been
using integration APIs that use attributes to differentiate different
messages types. So the following quote from Rick strikes close to home for
us:

    Why is containment more useful than subclassing
      line[@class="music"] and line[@class="graphics"]
    or specialization
      line[@type="multisegment"] and line[@type="single"].   
    This kind of need is much more common than
    having uncoordinated development within one
    namespace.

We have had to create alternative integration APIs that use intermediate
elements instead of attribute values, and we have done so for no other
reason than to ensure that our integration APIs are expressible with XML
Schema.