RE: Multiple result-documents, client-side transformations, and U RIs

> Perhaps to bring it closer to the WG's sphere of interest, 
> using the document function, in 1.0, produces quite a variety of 
> results; with minimal consistancy. 
> http://www.dpawson.co.uk/xsl/rfc2396/ shows > the lack of consistancy.

Your analysis is interesting, though not entirely surprising. The "file" URI
scheme has never been especially well defined in the RFCs; one reason for
this is that the RFC does not even attempt to define the detailed mapping of
these URIs to the file naming conventions of individual operating systems.

It's disappointing if the "file" or any other URI scheme is less
interoperable than one would wish, but I don't think this is something that
falls within the remit of the XSL WG to tackle.

> 
> One of the authors of the rfc states that the update is 
> currently being worked.
>   It does leave a mess behind, even if out of scope of the 
> wg. http://www.w3.org/Addressing/rfc1738.txt may be an 
> improvement, I don't know.
> 
> The reference from the current wd's is definitely within your 
> remit, especially after the comments on this thread.
> 
> are there alternatives?
> 

No, I think the URI/URL specs are generally weak, especially those for
schemes other than HTTP. We are actually moving somewhat in the opposite
direction. Given the success of the URIResolver mechanism in JAXP, we are
recognizing that the mapping from URIs to actual documents is something that
can be controlled by the implementor and/or the user and that it therefore
belongs in the dynamic context.

Anything that improves the interoperability of URIs will of course be very
welcome to XSLT users, but the XSL WG is not the owner of this particular
problem.

Michael Kay

Received on Monday, 19 May 2003 05:36:42 UTC