[
Lists Home |
Date Index |
Thread Index
]
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.
...
|
