Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Another errata?
 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@i... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
