Re: Namespaces, schemas, Simon's filters.

[Richard Tobin <richard@cogsci.ed.ac.uk>]

>>> 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.

I don't understand your argument here.  You say the the problem is
that local elements exist at all, but the rest of your posting is
directed entirely at the unqualified case.

The question of whether local elements are reasonable in general is
just this: should the name of an element identify its type (= content
model, essentially) regardless of its placement, or should elements
with the same name be able to have different content in different
contexts?  I'm sure most people are familiar with the situation where,
say, both a book and its author have a name and it seems natural to
model this with two elements both called "name" (and in the same
namespace).  The B&D school may not like it but it's so often the
natural thing to do that it's right that schemas support it.

Back to the qualified/unqualified issue:

><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.

At the risk of being repetitive: the most reasonable (IMO) argument
for this style (ie unqualified local elements) is that it parallels
the way attributes work.  Unqualified elements are scoped by the
containing element, just like unqualified attributes.  It lets you
have structured attributes.  (I don't find this argument convincing
enough that I use unqualified child elements myself.)

>Applying Simon's filter will
>put "shipTo" in the apo namespace.  This behavior totally
>flies in the face of XML+Namespaces as specified.

Right, if you don't like the unqualified style, it converts it
to the qualified style for you.

>Also, if
>I read schemas right, it also won't schema-validate any more.  

Naturally, you have to rewrite the schema (or validate before
conversion).  Probably this just involves adding
elementFormDefault="qualified" to the schema element.  Perhaps someone
could write a filter to do it :-)

-- Richard