RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceProcessing)

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Martin,

Suppose we take the intelligent step of eliminating element/attributeForm
attributes from XSDL.  The only change in expressivity with regards to XSDL
is the elimination of the following:

<complexType ...>
 ...
  <element name = "foo" ... form="qualified"/>
  <element name = "foo" ... form="unqualified"/>
 ...
</complexType>

whose status I consider open to debate, as I think the spec is actually
somewhat ambiguous on this point, and in any case I think it's a really bad
idea (but you know that already).  Oh, and the schema author loses the
ability to drive the instance author crazy by tweaking form for every
element and attribute in the schema (which was not what I thought I was
voting for at the time).  I'm happy to reduce the opportunities for
sadomasochistic behavior in XML development while not denying individuals
their right to engage in such behavior in other areas of their lives.

Now suppose we created implied attributes xsi:elementForm and
xsi:attributeForm with values "qualified" and "unqualified" (both with
default values of "unqualified") that were local to the element they appear
on.  Now, if no one uses these, we get exactly the behavior we have now if
everyone uses the defaults.  If someone sets xsi:elementForm on their root
element to "qualified" we get exactly the same behavior as if the author of
the schema had set elementFormDefault to "qualified".

Ambiguities arise in the instance under the following conditions:
1) if elementForm is unqualified and there is an unqualified top-level
schema (i.e., xsi:noNamespaceSchemaLocation was used) and there is a name
clash in a particular element.
2) if elementForm is qualified and both a locally scoped element and a
global element (both from the same schema, both with the same local name)
appear as siblings
3) a combination of the above - a locally scoped element and a global
element from the same schema, as well as a global element from a schema with
no targetNamespace, all with the same local name, all appear as siblings in
the same element.

case 1 is handled by putting xsi:elementForm="qualified" on the scoping
element
case 2 is handled by putting xsi:elementForm="unqualified" (i.e., leaving
the default) on the scoping element
case 3 can't be handled currently, as far as I can tell, anyway.  What it
shows is that xsi:noNamespaceSchemaLocation should be allowed to contain a
dummy namespace which can be used in the instance to allow items from that
namespace to be qualified in the instance.  Note that such a change could
also be used for condition 1.

From the processing/validator perspective, there's no big deal.  Software
that can handle current xmlns conventions should be easily modifiable to
handle this.  If anything, while parsing may become marginally (if at all)
more complex, all other processing should become simpler, especially as the
schema components no longer need to concern themselves with reflecting the
minutiae of this.

Oh, and the "initial designer of a given XML vocabulary" no longer "needs to
decide ... the namespace qualification of the elements and/or attributes in
that vocabulary," only the local names.  Much easier.

Matthew



> -----Original Message-----
> From: Martin Gudgin [mailto:marting@develop.com]
> Sent: Friday, August 17, 2001 1:42 PM
> To: Fuchs, Matthew; Xml-Dev
> Subject: Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> NamespaceProcessing)
> 
> 
> 
> ----- Original Message -----
> From: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>
> To: "Xml-Dev" <xml-dev@lists.xml.org>
> 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@develop.com]
> > > 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@lists.xml.org
> >
> > -----------------------------------------------------------------
> > 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>
>