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.



On 19 Aug 2001 12:48:26 -0700, Tim Bray wrote:
> 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. 
> 
> 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.   Near as I understand it, 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
> this 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 
> children whose type is Y and whose parent is myNS:Z."

For me, this is pushing scoping to an unreasonable extreme.  I've never
been especially comfortable with the declaration-applying-to-descendants
model Namespaces in XML eventually chose, and having to keep track of
"no-namespace children" is, well, pretty grotesque to me.  (Remember, I
work in SAX most of the time, and find the machinery added to DOM to
support namespaces already excessive.)

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

Precisely.

> OK, but now I have a problem.  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.  That's the whole point.  
> 
> So why would Simon's filters help? -Tim

They would help if you find the entire approach blessed by XML Schema to
be noxious, but still design systems which are intended to process a
wide variety of possible input documents.  

Given  my perspective as someone working with SAX, the filters (at least
com.simonstl.namespace.elements.ElementNamespaceFilter and
com.simonstl.namespace.elements.AnnotElementNamespaceFilter) provide a
means of dealing with this design pattern without requiring me to change
my assumptions about namespace processing in any significant way.  It's
effectively a minimal-lifting solution to the potential problems.

Force-qualification and the less-imposing annotation provide the
information about namespace context that I would otherwise have to
provide in my application.  Given that I don't ever use the PSVI, nor
recommend its use, this solves a local problem for me as the recipient
of documents written in a style I would never author.

You might want to take a look at the RDDL documents for the rules files
for these filters:
http://simonstl.com/ns/namespaces/elements/
http://simonstl.com/ns/namespaces/elements/annotate/

(com.simonstl.namespace.attributes.AttributeNamespaceFilter solves a
somewhat similar issue for attributes that seems to trouble RDF in
particular.  The other filters at
http://simonstl.com/projects/namespace/ are pretty much utility filters
for modifying namespace information in various contexts.)

I'm happy to admit that this is a perverse bit of code -
the world just sometimes needs perversity, perhaps as a coping mechanism
for other perversity.

Simon St.Laurent
http://simonstl.com