[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Namespaces, schemas, Simon's filters.
- From: Tim Bray <firstname.lastname@example.org>
- To: email@example.com
- 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
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.
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