RE: [xsl] Re: Identity transformation for XSLT 2.0

Subject: RE: [xsl] Re: Identity transformation for XSLT 2.0
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Sun, 23 Dec 2007 17:31:30 -0000
> "Since saxon:parse() and saxon:serialize() should have been 
> part of the spec"
> 
> Why?
> They are unnecessary.

I agree, it would be nice to make them part of the spec.

The fact that something can be coded in XSLT is not itself an argument not
to include it in the standard function library. That argument can be used to
show that you don't need a "+" operator, because people can always write
"--".

I don't think it's necessarily an argument againt providing an extension
function either. One of the often overlooked features of XSLT 2.0 is the
parameter override="no" which effectively allows you to use extension
functions in a portable way by providing an XSLT implementation as a
fallback if the extension function is not available.
 
> Saxon:parse has always been unnecessary.
> Parsing can be done with the fn:doc() function - just pass a 
> data: URI (RFC 2397).

I'm sorry, but I've always thought of this as a pretty bizarre workaround.

The RFC itself says that the data: URL scheme "is only useful for short
values". And asking users to encode their XML fragment correctly as a data:
URI just so that Saxon can decode it again seems too much like hard work and
too error-prone. 

Saxon does of course allow you to use this URI scheme (or any other) by
means of a user-written URIResolver, and if there were evidence that users
wanted to do this then I would certainly consider including this
functionality in the default URIResolver. But I haven't seen such evidence.

> If Saxon still doesn't support this 9-year-old standard, then 
> you can resort to writing a my:doc () xsl:function using 
> use-when to test the xsl:vendor system-property to identify 
> saxon, and use saxon:parse in that case, and use fn:doc() for 
> other cases.

Or write an XSLT function called saxon:parse with the parameter
override="no".

Incidentally, it isn't a standard, it's an RFC. It "requests discussion and
suggestions for
improvements." RFCs only become standards if the community chooses to treat
them as such. For this RFC, such acceptance has certainly not been
universal. The approach in Saxon is to implement the most popular and
portable URI schemes in the standard URIResolver, and to allow other URI
schemes to be implemented using user-written or third-party plugins.

Michael Kay
http://www.saxonica.com/

Current Thread