[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fw: Namespaces does *not* formally introduce "global attributes"
>Oren Ben-Kiki writes: > > AHA! So the namespaces proposal _DOES_ go beyond simply qualifying > > names with URIs! David Megginson <david@m...> wrote: >No it doesn't. Well it certainly got a lot of people confused about it. Luckly we are only wasting bandwidth as a result, instead of rain forest products :-) >The comment to which Oren is replying contains a common (but >understandable) mistake. ... > The source of the misreading is the unfortunately obfuscatory appendix >A.2, ... >I will recommend dropping A.2 in future drafts. That would be a relief :-) >In any case, what does all this have to do with transformation? Simple - if the XML namespaces recommendation was defined by an equivalence to a well defined textual transformation, then much confusion would have been avoided. For example, how namespaces interact with the other XML standards - just extend the names first, then apply the other standards (with a very small number of exceptions, such as namespace patterns in XSL). Additionally, implementers would have been able to easily add a namespace processing module on top of their current XML parsers (a SAX namespace expansion filter, for example, is trivial when implemented this way), _without changing the interfaces_. Future implementations might use better interfaces - such as APIs for accessing just the "namespace part" or the "local part" of an expanded name - but the point is every XML application would go on working as it is, without any changes. James has mentioned in his paper the WG has deliberately decided not to go this way. Could you tell us why this decision was made? An obvious consequence of this decision is that implementers were hesitant to implement namespaces this way. I hope this wasn't the reason :-) This happened because first, it wasn't clear that this approach is in fact conformant. Well, we got this out of the way - James says it is and you explained why (ignore the non-normative Appendix A). Second, because competing textual forms were suggested (the '^' notation, the '{}' notation). Since the WG wasn't kind enough to give us a standard notation, why can't we just pick one on our own and go with it? I'm partial to the '^' notation, myself, since it is (i) shorter, (ii) easier to read, (iii) slightly easier to process, and (iv) more in tune with the conventional hierarchy naming schemes (using a separator instead of parenthesis). Actually, has anyone already written a SAX filter which implements namespaces this way? Is anyone interested? Let's settle this once and for all - "proof by implementation" :-) Have fun, Oren Ben-Kiki 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
|