[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [good] Question about NS 1.1
Richard Tobin wrote: > > >I can't really get my head around my > >question-- but it is something like this: if there is a simple software > >solution to make namespaces work-- even for parsers that weren't originally > >designed to support them they can't be that broken. > > I agree. Carrying in-scope namespace information around doesn't have > to involve anything more than keeping some objects isomorphic to > namespace attributes. The questions remain, where are they kept and how are they combined? > If the document is not something that's > actually been parsed - the output of an XSLT module perhaps - then > some of those objects won't directly correspond to namespace > attributes, but they won't be any more complicated. It remains to be shown, that "they won't be any more complicated". The issue is not the immediate objects which "correspond to namespace attributes", but their management. > > In particular - in case this isn't obvious - there is certainly no > need to build a set of namespace bindings for all the namespaces in > scope on every element. Perhaps, but it is not intuitively obvious to the casual observer, that there is no need to be able to build a set of namespace bindings for all the namespaces in scope on every element. Furthermore, it is not obvious, that, where the "carrying in-scope namespace information around" paradigm is understood to encompass the "QNames-in-content are text" paradigm, the effect is that one must be able to build - and combine - the set of namespace bindings in scope on every character information item. > ... > > >1) QNames in content (but again a layer could add support for this > >downstream?) > > Certainly there would be no need to carry around any namespace map > if prefixes were only used on element and attribute names. > > >2) Joe English's sanity breakdown (which is actually genius...) > > I'm too lazy to go into this in detail, but there are reasonable uses > for some of the "insanities" he describes, such as combining two > documents that happen to use the same prefix. > > >3) The need to undeclare in scope namespaces (linked to 1?) > > I don't think this adds any significant complexity to namespace > processing. If it had been present in the original spec no-one would > have thought twice - it's a natural feature that was omitted (I think > Tim Bray - one of the original authors - has described its omission as > "a bug"). > > Rectifying this omission by issuing an erratum to Namespaces 1.0 would > have led to interoperability problems far out of proportion to the > advantages. It needed a change to the XML version number to do it > cleanly, and I don't think anyone thought it was worth a version > number change just for that. But when the XML 1.1 work started, > several people noted that if there was going to be a new version > number anyway, there was a handy opportunity to add prefix > undeclaring. > It is not obvious how the ability to undeclare a prefix eliminates the problems which the "carrying in-scope namespace information around in order to permit QNames-in-content" paradigm otherwise entails. ...
|
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
|