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

Namespaces, schemas, Simon's filters.

• From: Tim Bray <tbray@t...>
• To: Xml-Dev <xml-dev@l...>
• Date: Sun, 19 Aug 2001 12:48:26 -0700

Having spent some time reading this thread, I realized I 
didn't understand either local types or Simon's filters.  
As Ron Bourret said:

>> I think the real culprit here isn't whether local element 
>> type names are
>> qualified or not. It's that local element types exist at all. 

Upon further study, I think Ron's right.  For those who haven't 
already, some study of 

  http://www.w3.org/TR/xmlschema-0/#NS

is pretty essential.   Pardon me for offering an explanation of
something that will be painfully obvious to the students and 
authors of XSD around this list, but *if* I understand the 
motivation, it's this: people want to use schema X to validate 
element Y, but they don't want element Y to be in a namespace 
(even a defaulted namespace), they want the connection picked up 
from the namespace of an ancestor element, and "local element 
types" allow this.

At one level this seems like a reasonable thing to want to do: 
"please use the following rules to validate no-namespace 
elements whose type is Y and whose ancestor is myNS:Z."

On the other hand, it does contravene the achingly-simple
procedure for linking markup to software provided by 
XML+namespaces: identify markup to software by putting it
in a namespace.  Which feels pretty serious.  The default, 
simple, obvious way of arranging for software module X to 
process element Y is to advertise that X processes elements 
which are in the NSx namespace.  It's kind of troublign that 
schema supports a non-interoperable, more complex, less 
robust way of tying markup to software.  That this is its 
default behavior is simply outrageous.  As it stands with 
XSD, by default the way that schemas are tied to certain 
classes of elements is non-interoperable with the way that 
other software does it.  I REALLY HOPE that my understanding
of the motivation and effect is wrong and ask that someone
more schema-savvy explain why this isn't as awful as it 
looks.

On the other hand, I (and a lot of other people) declined
to take part in the schema effort, and the default 
assumption is that we have to live with it as specified.

Now, suppose I'm right.  If so, why are Simon's filters 
ever a good idea?  The XML Schema Rec allows me to write
rules so that in the following

<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
                   orderDate="1999-10-20">
 <shipTo country="US">
  <name>Alice Smith</name>
  <street>123 Maple Street</street>
  <!-- etc. -->

the "apo" schema is used to validate the <shipTo> element.
Nowhere does it say that the "shipTo" element is or should
be in the "apo" namespace.  Applying Simon's filter will
put "shipTo" in the apo namespace.  This behavior totally
flies in the face of XML+Namespaces as specified.  Also, if
I read schemas right, it also won't schema-validate any more.  
So why would this ever be a good idea?  -Tim

• Follow-Ups:
  • Re: Namespaces, schemas, Simon's filters.
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Richard Tobin <richard@c...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Peter Piatko <piatko@r...>

• Prev by Date: Re: "Uh, what do I need this for" (was RE: XML.COM: How I Learned t oLove daBomb)
• Next by Date: Re: Namespaces, schemas, Simon's filters.
• Previous by thread: Re: "Uh, what do I need this for" (was RE: XML.COM: How I Learned t oLove daBomb)
• Next by thread: Re: Namespaces, schemas, Simon's filters.
• Index(es):
  • Date
  • Thread