[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Namespaces, schemas, Simon's filters.

• From: Tim Bray <tbray@t...>
• To: xml-dev@l...
• Date: Thu, 23 Aug 2001 13:45:46 -0700

At 10:56 AM 23/08/01 -0700, Fuchs, Matthew wrote:

>Actually, while I've argued as to why making local elements unqualified is a
>good thing from the point of view of what local elements are, no one has
>given a similar argument for why local elements should be qualified.  

Let's ask two questions:

Q1: Why would you use XML?  
A1: One of the important reasons is so that you can re-use data for
purposes other than those envisioned by its creator.  This is why,
in the document space, XML is an unqualifiedly better storage 
format than MS Word, Frame, PDF, or any other proprietary binary 
display-oriented format.  A lot of the XML-as-serialized-objects
people probably don't care that much about this, but I think 
they're missing an important boat.  Computers are important 
because they are *general-purpose* machines, and to the extent 
that you can make data general-purpose as well, you win.

Q2: Why would you use namespaces?
A2: One of the important reasons is so you can pull together data 
objects from multiple sources without losing track of where the
pieces come from.

If you believe A1 and A2, then it seems to me like you get 
maximum re-usability and ability to mix-n-match if you've got
everything unambiguously and completely labeled with minimal
reliance on context.  

Let's make this concrete.  Suppose you have

<myNS:x>  <y> .. </y>   </myNS:x>

and you're counting on the software that processes <myNS:x> to 
know how to deal with a child <y>.  If someone else comes
along and slips in 

 <myNS:x> <html:a href="somewhere"> <y>...</y> </html:a> </myNS:x>

then the <y> looks a little lost, and 

 <myNS:x><html:a href="somewhere"><myNS:y>...</myNS:y>
        </html:a></myNS:x>

has a better chance of being processed by myNS-sensitive software
in a reasonable way downstream.

Also, suppose you have 

<myNS:x>  <y id="1340975"> .. </y>   </myNS:x>

and that a hyperlink from somewhere entirely outside points at 
<y> by the ID value.  Software processing such a is not 
in general going to have any way of knowing that this element really 
needs to be processed in the context of the containing <myNS:x>.

I think that the above are good and reasonable things to do, and
one of the Really Good Things about XML is that it opens the
door to these kinds of practice.   I think that markup designed to be 
robust in the face of general enrichment, manipulation, and
hypertext is better than markup that isn't.   At a deep level.

 -Tim

PS: And since the title line mentions Simon's filters, they look
to me like well-done software, but I continue to believe that
they should never be used, since they (a) fly in the face of
the author's intent as regards namespaces, and (b) they break
schema validation.

• Follow-Ups:
  • RE: Namespaces, schemas, Simon's filters.
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: Namespaces, schemas, Simon's filters.
    • From: Peter Piatko <piatko@r...>

• References:
  • RE: Namespaces, schemas, Simon's filters.
    • From: "Fuchs, Matthew" <matthew.fuchs@c...>

• Prev by Date: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespaceProcessing)
• Next by Date: Re: More Namespace Validation Problems
• Previous by thread: RE: Namespaces, schemas, Simon's filters.
• Next by thread: RE: Namespaces, schemas, Simon's filters.
• Index(es):
  • Date
  • Thread