[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespacePro

• From: Martin Gudgin <marting@d...>
• To: "Fuchs, Matthew" <matthew.fuchs@c...>,Xml-Dev <xml-dev@l...>
• Date: Fri, 17 Aug 2001 21:41:32 +0100

----- Original Message -----
From: "Fuchs, Matthew" <matthew.fuchs@c...>
To: "Xml-Dev" <xml-dev@l...>
Sent: Friday, August 17, 2001 9:00 PM
Subject: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
NamespaceProcessing)


<SNIP>
> Which comes to why the solution arrived at by the W3C Schema WG is
> problematic - the real issue is how the _instance_ author wants to use
> qualification to convey information about his document.
> The _schema_ author
> cannot know what elements will appear in the instance, or which schemas
will
> be mixed.  Therefore the appropriate solution would be to get rid of
> elementFormDefault and provide appropriate mechanisms in the _instance_ to
> specify how this should work for the particular instance under
> consideration.

I can't for the life of me see how this would work. I accept that the
initial designer of a given XML vocabulary needs to decide the local names
and namespace qualification of the elements and/or attributes in that
vocabulary. However, all other authors of documents for that vocabulary must
follow the rules layed out by the initial designer. These rules are what a
schema describes. I as a document author of, say, an XSLT document may
prefer to not bother qualifying elements but if I chose that path then the
resulting document would not be XSLT. And if I ran that document through an
XSLT processor it would not be processed as XSLT. If every instance author
basically gets to choose whether or not they qualify elements and attributes
I can't see how processing software is going to be able to make sense of the
result. Sounds like the worst of both worlds to me

Martin Gudgin
DevelopMentor

>
> Matthew
>
> > -----Original Message-----
> > From: Aaron Skonnard [mailto:aarons@d...]
> > Sent: Tuesday, July 31, 2001 9:21 PM
> > To: Xml-Dev
> > Subject: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> > NamespaceProcessing)
> >
> >
> > <snip/>
> >
> > [Simon]
> > > Namespaces in XML provides a means of pinning down element and
> > attribute
> > > identifiers to avoid potential conflicts.  By blessing the use of
> > > unqualified names within namespace-qualified contexts, W3C
> > XML Schema
> > > makes precise identification of those identifiers a much
> > more complex
> > > task.
> >
> > On the contrary, consider the following XML schema definition
> > and sample
> > instance document:
> >
> > <!-- schema definition -->
> > <s:schema xmlns:s="http://www.w3.org/2001/XMLSchema"
> >     xmlns:tns="http://example.org/foo"
> >     targetNamespace="http://example.org/foo"
> >     elementFormDefault="qualified">
> >   <s:element name="bar" type="s:string"/>
> >   <s:complexType name="fooType">
> >     <s:sequence>
> >       <s:element name="bar" type="s:string"/>
> >     </s:sequence>
> >   </s:complexType>
> >   <s:element name="foo" type="tns:fooType"/>
> > </s:schema>
> >
> > <!-- instance -->
> > <f:foo xmlns:f="http://example.org/foo">
> >   <f:bar/>   <--|
> > </f:foo>        |
> >                 |
> >                 |
> > Even when everything is qualified, you still can't figure out
> > which bar
> > element this is just by looking at the QName and ignoring
> > context (is it
> > the global or local qualified bar element?).
> >
> > And since everyone's already used to dealing with attributes based on
> > context [1], I don't see why local elements complicates
> > things further.
> > As an example, consider the version attribute in XSLT. When used on a
> > literal result element, it must be qualified. But when used on the
> > xsl:transform element, it must be unqualified, depending completely on
> > context.
> >
> > The only thing that matters is that both sides know when local scoping
> > is in use - either via schema definitions or human readable specs.
> > Whether or not it's harder to process locals vs. qualified elements is
> > debatable.
> >
> > [1] http://www.w3.org/TR/REC-xml-names/#ns-breakdown
> >
> > -aaron
> >
> > DevelopMentor
> > http://staff.develop.com/aarons
> >
> >
> >
> > ------------------------------------------------------------------
> > 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 unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@l...
>
> -----------------------------------------------------------------
> 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>

• References:
  • RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceProcessing)
    • From: "Fuchs, Matthew" <matthew.fuchs@c...>

• Prev by Date: RE: XML.COM: How I Learned to Love daBomb
• Next by Date: RE: XML.COM: How I Learned to Love daBomb
• Previous by thread: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceProcessing)
• Next by thread: Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespaceProcessing)
• Index(es):
  • Date
  • Thread