OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Namespaces, schemas, Simon's filters.





> -----Original Message-----
> From: Richard Tobin [mailto:richard@cogsci.ed.ac.uk]
> Sent: Sunday, August 19, 2001 2:41 PM
> To: tbray@textuality.com
> Cc: xml-dev@lists.xml.org
> Subject: Re: Namespaces, schemas, Simon's filters.
> 
> 
...
> 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.)
> 

The very notion that this is a style issue argues for moving it out of the
schema and into the instance.  However, as I argue in another message, there
are consequences for how easy it is to distinguish local from global during
processing.

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

Right - since this is an instance transformation, let's keep this issue in
the instance.

> >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 :-)

But if elementFormDefault were in the instance, I wouldn't need to rewrite a
schema I don't have write access to.

Matthew