OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [good] Question about NS 1.1

[ Lists Home | Date Index | Thread Index ]

>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.  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.

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.  (XPath 1.0 has some extra complication for
implementors because namespace nodes have parents, and I think that is
now recognised as a mistake.)

> It feels like there are
>two (maybe three) notions of what the problem is:

>1) QNames in content (but again a layer could add support for this

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

-- Richard


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS