[
Lists Home |
Date Index |
Thread Index
]
- From: "James Tauber" <jtauber@jtauber.com>
- To: "XML-Dev Mailing list" <xml-dev@ic.ac.uk>
- Date: Mon, 30 Aug 1999 10:12:26 +0800
I was originally a one-namespace supporter on the grounds that capturing the
commonality between element types in the different XHTMLs was valuable.
Then I was persuaded that the purpose of namespaces is to make sure that if
two "p"s mean two different things, they can be distinguished, **NOT** that
if two "p"s mean the same thing, they can be expressed the same way.
This made me tend towards being a three-namespace supporter.
However, as David Megginson and Tim Bray have argued, capturing the
commonality between, say, "p" in each DTD is not just valuable, but pretty
much vital.
It seems to me that this is an argument to expand the role of namespaces (to
express commonality, not just distinction) on grounds of practicality.
I imagine that most people would agree that:
1. There is a difference between strict:p and transitional:p
2. The difference is small and most applications will not care about it
3. Most applications *will* care about the commonality
But the fact of the matter is that it is application-specific. Yes, it may
be the case that 99.9% or more of applications care about the commonality,
not the difference, but what we ultimately need is a means for the
applications that care about the difference to be able to distinguish
strict:p and transitional:p and those (the majority, admittedly) that don't
care, to see them as the same.
To use, as others have done, the example of natural language: there are some
applications that just want to know if X is in English and some applications
that need to know whether X is US English, Australian English, Encarta
English, or whatever.
The one-namespace supporters would probably say:
* use namespaces to recognize commonality
* use DTD identifier to recognize difference
The three-namespace supporters would probably say:
* use namesapces to recognize difference
* use some other mechanism to recognize commonality
What I would like to see is some alternative mechanisms put forward to
recognize commonality.
Here are a couple of possibilities:
1. PREFIX MATCHING ON NAMESPACE URIs
Use URIs to develop a hierarchy of namespaces and then allow
underspecification for matching via prefixes.
Use the Namespace URIs:
http://www.w3.org/HTML/Strict/1.0
http://www.w3.org/HTML/Transitional/1.0
and allow applications to match
http://www.w3.org/HTML
or
http://www.w3.org/HTML/Strict
or
http://www.w3.org/HTML/Strict/1.0
depending on what they care about
PRO: uses existing namespace mechanism
CON: would require modification to XPath, etc.
2. A COMMON ATTRIBUTE THAT CAN BE MATCHED
Have all elements in all three DTDs take a FIXED attribute. For example:
w3c:vocab="HTML" xmlns:w3c="http://www.w3.org/"
Then applications can match
- by namespace
or
- by "vocab" attribute
depending on what they care about
PRO: doesn't require modification of XPath, etc.
CON: invents new mechanism
What do people think?
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
<pipe>Ceci n'est pas une pipe</pipe>
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|