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

Re: "Clean Specs"

• From: "Rick Jelliffe" <ricko@a...>
• To: <xml-dev@i...>
• Date: Tue, 9 Feb 1999 02:18:40 +1100

From: Ronald Bourret <rbourret@i...>

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
point
>and one that has bothered me during this whole discussion.  Tim is
>absolutely correct here -- the namespaces spec is *way* better than the
XML
>spec.

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
find
it interesting or useful. I would don't want to put it on a public
website,
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
one
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
honest,
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
useful.
>
>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
readers
is a great discipline. Perhaps specs should clearly include at their
head a
notice stating the intended readers.

Rick

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 value.

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".

	[ namespace name, element name,  attribute name]

<?xml version="1.0"?>
<!-- initially, the default namespace is "books" -->
<book 
	xmlns='urn:loc.gov:books'
	xmlns:isbn='urn:ISBN:0-395-36341-6'>
	<title>Cheaper by the Dozen</title>
	<isbn:number>1568491379</isbn:number>
	<notes type="commentary">
		<!-- make HTML the default namespace for some commentary -->
		<p 
			xmlns='urn:w3-org-ns:HTML'>
			This is a <i>funny</i> book!
		</p>
		<!-- use the default local namespace too -->
 		<local value="override with "/>
	</notes>
</book>

	['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, ]
	['urn:ISBN:0-395-36341-6', number,]
	['urn:w3-org-ns:HTML',p, ]
	['urn:w3-org-ns:HTML',i, ]
	[ ,local, ]

	['urn:loc.gov:books', notes, type]
	[ ,local, type]

	<!ELEMENT ename ANY >
	<!ATTLIST ename
		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".

Furthermore I think it might aid the wordsmithing of the final main text, and also prepare better for future namespace development. 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.

Rick Jelliffe, Computing Center, Academia Sinica, Taipei

• Prev by Date: Re: CORBA's not boring yet. / XML in an OS?
• Next by Date: Re: CORBA's not boring yet. / XML in an OS?
• Previous by thread: "Clean Specs"
• Next by thread: Fw: "Clean Specs"
• Index(es):
  • Date
  • Thread