rationale for xml:base design in xml-attributes

This message is primarily intended to be linked to from the documentation.
http://www.w3.org/2003/g/xml-attributes

xml-attributes provides for processing of xml:base.

Unlike other approaches to xml:base this module does not do relative 
reference resolution.

Instead it permits for moderately clever copying of relative references 
from the input tree to the output tree so that the relative references 
in the output tree necessarily resolve to the same URIs as in the input 
tree.

The motivation for doing this is:
- XSLT1 does not provide native xml:base support.
- The standards for relative reference resolution are, in my opinion, 
moderately complicated, and have flux in corner cases (e.g. resolving 
../../../../foo against http://ex.org/a/b in RFC 3986 vs 2396)
- I think it is thus harder to provide correct code for relative 
references than merely the correct manipulation of xml:base values. The 
xml:base rec is very straightforward.

It is a key goal that library code should work, and have a very low 
support/maintenance overhead; since I do not believe we have a 
convincing story on support.

====

Other options were:
- use forward compatible processing to use XSLT2's xml:base support.
   Rejected because libxslt in particular, may have defective forward 
compatible processing.
- use the W3C URI lib
   Rejected due to complexity and support reasons.
   (Example issue as raised by Beckett is that the W3C lib generally 
prefers to be told the retrieval URI, which is not available in our 
context. It is unclear how possible it is to resolve a relative 
reference against another relative reference to find a third equivalent 
relative reference).

====

The key drawbacks with the approach taken:
a) it does not work in all cases. When it doesn't the approach of an 
abnormal termination (xsl:message terminate=yes) is used. i.e. if the 
code completes then it completed correctly.
b) the API is slightly more complicated than when relative references 
are resolved. The API-user needs to inform the module of the base used 
on the most immediate ancestor with a base (as computed by this module).

Jeremy






-- 
Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 25 June 2007 09:56:54 UTC