DOM WG comments on XBase Last Call draft

XBase and the Infoset would appear to have problems with respect 
to namespaces. XBase doesn't actually break namespaces; it just 
makes the problem worse. For a start, XBase should state clearly 
whether it should apply to namespace URIs or not. Given the 
problems associated with potentially relative namespace URIs and 
how they interact with xml:base, there is strong sentiment in the 
DOM WG that the XBase draft should not be considered finished 
until the interaction with namespaces is clarified. If it is decided that
XBase does not apply to namespaceURIs, because they could be 
considered sufficiently different to other URIs to warrant special 
handling, then this should be made clear in the XBase draft. Should
it be decided that XBase does apply to namespace URIs, then the 
DOM WG recommends that the XML Core WG set a small group 
of people the taks of figuring out the interaction. Although it would 
be possible for an updated namespaces specification to clarify 
whether XBase should apply to it or not, and therefore XBase itself 
would not need to specify this, saying that XBase should not define 
the interaction with namespaces would mean that the issues would 
continue to swirl and cause confusion until such time as a revised 
namesapces specification can be produced. Given the XML Core 
WG workload, this time could be significant, and the 
interoperability costs high.

The crux of the issue is that the definition of identical 
namespaceURIs talks about character for character matching, and
therefore namespaceURIs are not identical if one is relative and one
is absolute. Making the relative URI absolute by using XBase still
does not make it identical with an absolute namespace URI, even if
the URI obtained is the same by standard URI rules. The DOM, as 
a consequence, assumes the namespaceURIs to be unique strings 
and therefore has no way of making relative URIs absolute. Only 
the act of traversing a namespaceURI (with no guarantee of there 
being anything at the end of it) actually requires making the relative 
URI absolute, and so there has been no need to make relative URIs
absolute within the DOM up till now. 

The DOM WG is also concerned at the way the Infoset keeps 
expanding to include new drafts. We would like to see the Infoset 
finished, and expanding the scope to include XBase doesn't help, 
given the namespace problems we see.

Other comments on XBase, not related to namespaces:

there seems to be scope for misunderstanding whether the base 
URI is a property of the information item and therefore moves with it 
when it is moved (as for namespaceURI), or whether it is 
contextual. We request that the draft be edited to make this clear. 
The consequences of this can be seen in the following example.

Using the first option, if a portion of a document is relocated to fall 
under a different xml:base, it would retain the xml:base value it 
started with. In practical terms, this would mean that when the 
DOM is serialized out as XML, a "normalization" would have to be 
performed, potentially synthesizing new xml:base attributes to 
maintain that information. As a trivial example, given:
     <foo xml:base="a">
          <bar xml:base="b">
               <baz/>
          </bar>
     <foo>
... using the DOM to remove the <bar/> wrapper around <baz> 
would most likely yield:
     <foo xml:base="a">
          <baz xml:base="b"/>
     <foo>

However, as with DOM L2 support of Namespaces, that xml:base 
attribute would probably not appear until normalization is  
performed. Asking a node for its base URI via an appropriate API 
call would yield the right answer, but the attributes might not be in 
synch with that reality.

Similarly, changing the attribute might not change the node's base 
URI --  again, similar to how DOM L2 handles namespace 
declaration attributes.

regards,

Lauren Wood, Chair, W3C DOM WG

Received on Tuesday, 21 March 2000 00:29:52 UTC