[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Namespaces, schemas, Simon's filters.
- From: Tim Bray <tbray@textuality.com>
- To: Xml-Dev <xml-dev@lists.xml.org>
- 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