Lists Home |
Date Index |
- From: "Rick Jelliffe" <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Tue, 9 Feb 1999 02:18:40 +1100
From: Ronald Bourret <email@example.com>
Tim Bray wrote:
>> I think that (namespace) spec is *way* better than the XML spec.
I think the XML Spec is pretty good, actually. Tim and the others did
a great job.
>I've quoted this out of order because I think it is a very important
>and one that has bothered me during this whole discussion. Tim is
>absolutely correct here -- the namespaces spec is *way* better than the
The first draft-parts of the namespace spec (Appendix A) are lousy. And
I think they are incorrect. I am attaching the comment I sent in to the
namespace effort (alas too late), in the hope that some people might
it interesting or useful. I would don't want to put it on a public
because, having had my chance and having had my opinion not taken up,
I think it is poor sportsmanship to continue whinging.
I pushed hard early on for the PI approach. But I changed my mind for
reason only: the need to support HTML-in-XML and XML-in-HTML.
The major application of namespaces may well be embedding things in
HTML: the PI option is not realistic for a couple of years. To be
I don't think Namespaces would have been acceptable to HTML users
with the PI option. The need to support HTML developed as a goal during
the namespace discussions, and I consider it the key tradeoff factor.
>> This group is notably and vocally dissatisfied with the specs, I
>> am watching with attention for concrete suggestions as to how
>> to make future specs better - the one premise that seems to get
>> consensus, in this group at least, is "more examples
I am attaching my comment. Appendix A.2. and A.3 are poor in thought,
and close off nice doors that should be kept open.
>> Having said all that, people who write specs always have to try to
>> do a better job next time, so this recent discourse is very very
>Thanks for listening. I hope this has been helpful.
At ISO now, you have to have a user model for who you are writing the
spec for. Having a target education and technical background for your
is a great discipline. Perhaps specs should clearly include at their
notice stating the intended readers.
Names in Namespaces are a Triple
This comment does not effect the operation of namespaces from the current PR,
but it does propose a more elegant analysis and easier-to-understand exposition.
The length of the current proposal (more than 10 pages) is at odds with the needs
for straightforwardness. In particular, Appendix A2 and A3 would benefit.
The analysis problem flows from treating the element type name as being
different from other element values, rather than being an anonymous attribute
In the view of many, which I agree with, there is no necessary theoretical
justification for treating an element type name as being different from attribute
values. The important property of keying DTD content models for DTD validation,
but that is a matter of the particular operation of DTD validators, not intrinsic
to the element type names themselves. Indeed, "architectural parsers" use some
other attribute for this purpose; witness further the HTML SDAform attributes.
The unfortunate effect of analyzing the element type name differently from
attribute values is that the namespace PR becomes complicated, and its meaning
unclear. I propose the following analysis and exposition, which would replace
Appendix A.2 and A.3. There is no need to include any notion of "partitioning".
A.2 Expanded Names
Expanded names, for the purposes of this specification, are a triple:
[ namespace name, element name, attribute name]
- namespace name is
- a URI; or
- empty (i.e. anonymous namespace, -- the URI of the instance document)
- element name is
- the NCName of an element which belongs to the namespace or
- empty (i.e. the anonymous context -- used for a global attribute)
- attribute name is
- an NCName of an attribute, as currently stated or
- empty (i.e. the anonymous attribute -- used for the element type name)
With the meaning:
- [,,,] is the expanded name signifying a document's default namespace
- [,y,] is the expanded name signifying an element y within a document's default namespace
- [,,x] is the expanded name signifying any attribute x within a document's default namespace
- [,y,x] is the expanded name signifying any attribute y of an element x within a document's default
- [z,,] is the expanded name of the namespace signified by URL z
- [z,y,] is the expanded name signifying an element y within namespace z
- [z,,x] is the expanded name signifying any attribute x within namespace z
- [z,y,x] is the expanded name signifying any attribute y of an element x within namespace z
Thus the example:
<!-- initially, the default namespace is "books" -->
<title>Cheaper by the Dozen</title>
<!-- make HTML the default namespace for some commentary -->
This is a <i>funny</i> book!
<!-- use the default local namespace too -->
<local value="override with "/>
It contains the following expanded names:
['urn:ISBN:0-395-36341-6', , ]
['urn:w3-org-ns:HTML', , ]
['urn:loc.gov:books', , ]
['urn:loc.gov:books', book, ]
['urn:loc.gov:books', title, ]
['urn:loc.gov:books', notes, ]
[ ,local, ]
['urn:loc.gov:books', notes, type]
[ ,local, type]
A.2.2 Schema for Expanded Names
A schema for the expanded name is given below, using markup declaration syntax.
<!ELEMENT ename ANY >
xmlns CDATA #FIXED "editor: put URI of this document here"
namespace CDATA #IMPLIED
element NAME #IMPLIED
attribute NAME #IMPLIED >
I believe this version of A.2 and A.3 expresses the intent of the PR
with greater rigour, clarity, power and usefulness than the current text.
Note that this proposal would allow the definition of Namespace to become simpler:
[Definition:] An XML namespace is a set of composite names, identified by a
URI reference [RFC2369], which are used in XML documents as element types
and attribute names. The composition of these names is detailed in
"A. The Internal Structure of XML Namespaces".
I think it might aid the wordsmithing of the final main text, and also prepare better for future
For example, extending namespaces to include enumerations
in attribute values can be trivially accomplished by making the expanded name
a quadruple [ namespace name, element name, attribute name, enumeration name].
I might also say, that it contains no explanatory text which
may support particular hidden agendas, and so might prove
less contraversial and tedious for the editors and explainers of namespaces
than the current PR.
Computing Center, Academia Sinica, Taipei