OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Another errata?

[ Lists Home | Date Index | Thread Index ]
  • From: Mark Birbeck <Mark.Birbeck@iedigital.net>
  • To: XML Dev <xml-dev@ic.ac.uk>
  • Date: Wed, 3 Feb 1999 13:09:11 -0000

Ronald Bourret wrote:
> Mark Birbeck wrote:
> They *are* in the same "namespace", as the term is defined by the 
> namespaces spec.

Where is the term defined? "XML namespace" is defined, and then from
then on the word 'namespace' is used very loosely, but I so no
're-definition' of the term namespace away from its traditional meaning.
I DO see an explanation of how the concept of an 'XML namespace' differs
from a tradition 'namespace'.

> That this is confusing is evident from the above discussion 
> -- John means 
> XML namespace and Mark means traditional namespace.

I'm not confused thanks - I mean both. I am drawing a distinction. You
need both to understand how the namespaces spec implements 'traditional
namespaces' in a manner useful to XML. In short, one, traditional
namespace would not be enough for XML because you lose structure. It
therefore needs a lot of them, and this is achieved by having
effectively a 'namespace container' full of other (real) namespaces.
That namespace container is an 'XML namespace' - which for brevity, we
call a 'namespace'. (Hey, I'm not disagreeing with you that it's
tricky!!)

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

I suppose we're onto matters of opinion now, but a standard must be
unambiguous in its *formal* interpretation. I may read it and
misunderstand, but when I get down to the nitty-gritty of
implementation, provided that I eventually *do* understand it, I should
be able to do this unambiguously.

If you describe 'intent' then what if you do not cover a usage that
later arises? You introduce ambiguity.

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

The spec does not! The reader's mistaken assumptions about what the
namespaces spec is trying to achieve leads them to read this into it.
But if we're really honest here, if we were in a discussion group on
compiler technology ten years ago, you would not have such a wide range
of people discussing these issues, and narrower range of
misinterpretation (I'm not saying everyone understood everything then
either). That's not to say we shouldn't have more people involved, but I
disagree with this 'dumbing down' attitude that seems to exist, where we
must ensure that everyone can understand. If you want to write a book
making it clearer then do it - we'd all probably be grateful - but the
spec itself MUST be a formal document.

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

No! The job of the discussion *about* a spec is to find agreement. Once
that has been arrived at you need to codify that in a way that is
unambiguous. It needs to be as formal as possible!

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

I don't think that is the job of standards. Others can write books on
it, produce training courses, and as you say, get hamsters involved in
video production (although I believe that's illegal in some States) but
the standard itself must be as terse and precise as possible.

Mark Birbeck
Managing Director
Intra Extra Digital Ltd.
39 Whitfield Street
London
W1P 5RE
w: http://www.iedigital.net/
t: 0171 681 4135
e: Mark.Birbeck@iedigital.net


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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS