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.



Ron,

I think this is close, certainly closer than some are willing to
acknowledge.  One important thing is, you don't distinguish between valid
and well-formed.  You are basically looking at things from a validation, or
well-typed, perspective - as do I.  Evan and Tim are looking at it from a
well-formed perspective.  The NS rec means different things for each camp.
Let me slightly rewrite what you've written, and perhaps that will work
better.

> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@rpbourret.com]
> Sent: Friday, August 24, 2001 3:50 PM
> To: xml-dev@lists.xml.org
> Subject: Re: Namespaces, schemas, Simon's filters.
> 
> 
> I thought of a shorter summary of this:
> 
> 1) A fundamental assumption of XML is that element types are global.
1) A fundamental assumption of valid XML 1.0 is that each element has a
unique content model.  Elements in DTDs function like global elements in XML
Schema - there can be only one global element with a given local name in a
Schema, it has a fixed type, and it can appear in any type.
> 
> 2) The namespaces spec reinforces (1) by providing technology that
> allows people to make element type names be universally unique.

2) The namespace spec reinforces (1) by providing technology that allows
people to make element names and their valid types universally unique.
Again, this is only if you are interested in validation, where an element
has a specific type (content model).

> 3) Local element type names are not universally unique. They are only
> unique to their containing element type. (In this sense, they are
> similar to unqualified attribute names.) This contradicts (1).
> 

In the context of Schema validity, of course.  

> 4) If a local element type is in a namespace, (2) is no longer true.
> 5) To provide a workaround for (4), the XML Schemas spec allows local
> element type names to be in no namespace at all. This places them
> outside the scope of the namespaces spec. (Good practice: If you use
> unqualified local element type names, explicitly turn off the default
> namespace on the parent element in the instance document. Otherwise,
> they could accidentally end up in the default namespace.)
> 
> 6) Point (5) resolves the technical conflict between local 
> element type
> names and the namespaces spec, albeit in a somewhat sneaky manner. It
> does not solve the philosophical conflict between local element types
> and (1).
> 

Right - so people should get on the Schema WG's case to fix things
correctly.

Matthew