OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Namespaces, schemas, Simon's filters.

There were obviously many in the Schema WG who were convinced that local
elements do not contradict the NS rec.  It's not contradiction that concerns
me - the NS framework provided for local elements by XSDL is currently
insufficient, that's all.

Regarding syntactic sugar, all programming is syntactic sugar on machine
code, but without that syntactic sugar, computing would have never made it
out of the '50s.  Believe me, syntactic sugar is necessary.

Finally, with regards to using attributes to distinguish types, what else is


> -----Original Message-----
> From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
> Sent: Friday, August 24, 2001 5:34 PM
> To: 'Ronald Bourret'; xml-dev@lists.xml.org
> Subject: RE: Namespaces, schemas, Simon's filters.
> > 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.
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>