RE: 5.3 and Appendix A contradiction [Re: Another errata?]
james anderson wrote: > John Cowan wrote: > > > > Mark Birbeck wrote: > > > > > OK then, some have argued, at least shouldn't 'isbn' > automatically be > > > part of the 'bk' namespace? Still no, I'm afraid. Every > member of a > > > namespace is meant to be unique. > > > > Well, not quite. An element can have the same name as a global > > attribute without problem. [I've replied to this in the 'Another errata?' thread] > In a similar vein, one unqualified attribute defined for one > element can have > the same name as another unqualified attribute of another > element without > sharing the same declaration. A very odd response! Follow the three comments through: - in response to demands for more errata I say that an unqualified attribute should *not* automatically join the namespace of its element - as part of my justification I say that all members of a namespace must be unique, and then go on - John disagrees - although why I don't know, because that's what a namespace is - and backs up his argument by saying that an element and a global attribute can have the same name. But that doesn't prove that namespaces can have duplicates, because they are actually in different namespaces - and then James comes to his assistance by adding that an unqualified attribute for one element can have the same name as an unqualified attribute on another element BUT WHY?! Well ... because an unqualified attribute does not automatically join the namespace of its element!! If it did then you would have duplicates in your namespace, because they are different attributes. Sound familiar? > More than one kind of "namespace" is necessary to interpret > an xml document > which conforms to the spec. One kind of space maps QName's > and Name's to > identifiers. If we're going to pursue this to the bitter end ... you can't have a 'Name' in a conforming doc, they must all be 'QNames' (no colons except after a prefix). > The namespace spec itself does not do justice to this, and, in fact, > introduces - in relation to the notion of universal attribute > names - the > impression that XML requires a Name -> Identifier -> > Attribute-Declaration > mapping/namespace, when it does not. While one could accept > that the illusion > of such a namespace is helpful for things like XSL patterns, > this kind of > namespace is not entailed by the xml spec itself. It > specifies a mapping of > the form Name -> Identifier -> Identifier -> > Attribute-Declaration. That is, > it requires an element identifier in addition to an attribute > identifier in > order to identify a declaration. This may be true - that XML does NOT require this - but I think the spec rightly draws attention to its need in many applications. Take for example the difficulty of dealing with global attributes. Say that I want every single node in a magazine article to have a unique identifier so that if it gets edited I can put it back into the database easily. I might define: <xml xmlns="uri:magazines-r-us" xmlns:db="uri:mydatabasespec"> <article db:id="1"> <title db:id="2">My Article</title> <paras db:id="3"> <para db:id="4">An interesting thingy.</para> <para db:id="5">More of the same.</para> </paras> </article> </xml> Without the namespace spec, 'id' is in four different namespaces. Now you're right that each has context: article->id article->title->id and so on, but I disagree with you saying that this contextual information 'is enough'. What if I wanted to process all database 'id' values? Say my application needs to work out if any nodes have been deleted before returning the data to my database. Well OK, you could say, in XSL-style syntax: */attribute(id) or whatever it is. That is - give me all elements that contain an 'id' attribute. But what if we were to add an additional 'id' attribute, say for use by some other site to allow paragraphs to be quoted. And say also, that it was not a requirement of each node to have a database 'id' value. Then without namespaces we get: <xml> <article id="1"> <title id="2">My Article</title> <paras id="3"> <para id="a1p1">An interesting thingy.</para> <para id="a1p2">More of the same.</para> </paras> </article> </xml> Now my poor old database application cannot tell the difference between the database version of 'id' on 'article', 'title' and 'paras' and the reference version of 'id' on 'para' - unless of course we process every single node that comes back from the '*/attribute(id)' query, or we query for each of the possible types. But with namespaces I can say 'give me every id value in the uri:mydatabasespec namespace'. Of course, you could argue that I should just name my attributes something else - 'db:id' perhaps - and then I can query them uniquely. But what if I want to use two DTDs, and someone else has used 'db:id'? I'm back to square one again. Whichever way you turn, if you want to assist applications built on an XML processor - and I believe 'assist' is all that is being said in the spec - namespaces are very, very handy. 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/ 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