Another errata?

[Ronald Bourret]

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

<soapbox>
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 
job.

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 
will succeed.
</soapbox>

-- Ron Bourret


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)