Lists Home |
Date Index |
- From: Ronald Bourret <firstname.lastname@example.org>
- To: XML Dev <email@example.com>
- Date: Wed, 3 Feb 1999 11:02:09 +0100
Mark Birbeck wrote:
> How not quite? A namespace is a set of unique entries *by definition*.
> That's what they are - a set of unique entries. You can't have a 'set of
> unique entries' that contains a duplicate.
> > An element can have the same name as a global
> > attribute without problem.
> True. But they are not in the same namespace. According to A.2 the
> element would be in the 'all element types' partition, and the global
> attribute would be in the 'global attribute' partition.
They *are* in the same "namespace", as the term is defined by the
namespaces spec. The spec is, at times, quite forward about this -- for
example, section A.1. At other times, you need to read very closely to
determine whether the XML or traditional meaning of "namespace" is meant --
for example, in the paragraph describing per-element-type partitions, the
first and second uses of the word "namespace" mean "traditional namespace";
the third usage means "XML namespace".
That this is confusing is evident from the above discussion -- John means
XML namespace and Mark means traditional namespace.
> It is not the job of standards
> developers to make sure we understand everything they write. ...
Huh? It most certainly *is* the job of the standards developers to make
sure we understand what they write. What is the point of a standard if
nobody can understand it? Even more to the point, if what standards
writers write is routinely interpreted to mean many different things by
many different people, then I think the standards writers have failed their
The SQL specs may make for abominable reading, but they are generally
interpreted by everybody the same way. The XML spec is not the clearest
piece of technical writing ever to come down the pipe, but after reading,
and re-reading, and re-reading it, most people interpret most parts of it
in the same way.
In contrast, the namespaces spec *is* widely misinterpreted, and by people
who, judging by their posts to this list, are intelligent and more than
willing to read, re-read, and re-re-read specs. To me, that says there is
something wrong, and I think a good example of this is the fact that the
spec repeatedly leads the reader to believe that unprefixed attributes
belong to the namespace of the element.
I think a mistake made in writing many specifications is to rely on
excessively formal language and write down only the rules, not the
motivation. In my mind, the point of a specification is not to write
rules, but to get everybody to agree to the same rules. (These are not
quite the same thing -- think of the difference between the clue and the
answer in a crossword puzzle. If you have a clue that immediately leads
everybody to the same answer, then it is as useful as the answer, even
though it is not the same.) Thus, anything that will get people to come to
the same conclusion (stating the rules clearly, stating the motivation for
those rules, giving examples, linking to video presentation of pet hamsters
pantomiming the rules, etc.) is fair game.
Finally, if you are driving a technology through standards (as opposed to
the other way around, which is more common), then, whether you like it or
not, those standards necessarily play a role in marketing that technology,
and the more accessible those standards are, the more likely the technology
-- Ron Bourret
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)