Re: Problems with xmlns parts in XPointer

Hi Elliotte-- Here's a stab at an answer:

> I know it's past last call, but I just noticed this and it's a pretty
> serious issue. I hope you've already thought about it but just in case
> you haven't:
> 
> What happens when XPointers with xmlns parts are used in namesapce
> well-formed XML documents? In particular how does the namesapce
> declaration in an XPointer using xmlns interact with the namespace
> declarations defined by xmlns and xmlns:prefix attributes in the XML
> document? What if they conflict? Which one wins?

The xmlns() scheme is completely separate from the xmlns "tree" in the current document -- even if the XPointer points into the current document.  I think the example in 5.2.1 sort of points this out because it assigns a whole new prefix, "y", to the inner element that, in the pointed-to document, has a prefix of "x".  All that's important is matching the namespace name.

> The current draft seems to implicitly say in section 5.2.1 that xmlns
> attributes are completely irrelavant; that only xmlns parts can be used
> to binds URIs for prefixes found in an XPointer. This seems wrong to me,
> but perhaps its consistent.

You're right that no namespace context is "picked up" in interpreting xpointer() stuff.  We had originally allowed it to be picked up as a kind of shorthand, but got the comment that this introduces problems with copying and pasting URI references, since they're incomplete without the namespace knowledge.  Is the loss of the shorthand the reason why you say that having to use xmlns() is "wrong"?

> At the least, I'd like to see more explicit discussion of the meaning of
> xmlns attributes with respect to XPointers in the final draft, even if
> the semantics and syntax remain as they currently are. 

Do you have a suggestion for what should be added?

        Eve

Received on Sunday, 3 June 2001 21:31:16 UTC