Lists Home |
Date Index |
Ronald Bourret wrote:
> Assuming I read your example correctly, what you want to do is take
> element types x and y, which were not in any namespace, and, through a
> trick of default namespaces, declare them to be in the data:,ns-a and
> data:,ns-b namespaces.
I would not call this a trick.
> I find this abusive and no more correct than renaming x and y as Fred
> and Ginger.
Taken to the extreme, this characterisation implies that all element sets should include a fixed namespace declaration in their
"top-level" element(s). In which case the NAMESPACE notation is superfluous.
> They were not in any namespace, so when used in a compound
> document, they should continue not to be in any namespace.
Does the "default" namespace mean something different in a document definition than it means in the document entity?
The notion of "not in any namespace" is bogus. Unprefixed qualified names which appear outside of the scope of a default
namespace declaration are identified with universal names in a distinguished "null" namespace. For which there is an implicit
declaration. If there were not true, such names would be incommensuarable and validation would not be possible. That it is
possible to shadow this implicit declaration is no different than that it is possible to shadow an explicit declaration. No more
abusive and no less correct.
> Supporting this is quite easy using the NAMESPACE notation, with the
> proviso that one must be careful not to declare a default namespace.
> (This is similar to using non-namespaced elements in an instance -- the
> presence of a default namespace will cause these to be inadvertently
How is one to use a declaration with indefinite scope to emulate the lexical scope of attribute-based declarations within the