Re: [xsl] xslt/xpath 2.0 comments ( long )

Subject: Re: [xsl] xslt/xpath 2.0 comments ( long )
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Wed, 16 Jan 2002 11:38:34 +0000
Mike Kay wrote:
> Jeni's argument that we could do sequence manipulation in XSLT
> rather than in XPath is something that we'll revisit in the WG.
> Personally, I would hate to duplicate the functionality at both
> levels, and I'd like to have as much syntax shared with XQuery as
> possible so long as it doesn't compromise the design integrity of
> the language.

I agree that duplication is a bad thing (having too many choices is
confusing :) You can't deprecate the XSLT versions because you can't
make XPath do node construction (unless, of course, you go the whole
way and become XQuery). That's why I'd like the stuff that's already
done in XSLT to not also be done in XPath.

>> I was under the impression that one would be able to call a
>> template using function like syntax; my:template(param,param,...)
>
> No, there's no proposal to do that. Arguably, named templates are
> now redundant, since you can always replace a named template with a
> function (that returns a temporary tree), and call it as
> <xsl:copy-of select="my:function(params)"/>;

Quite. If functions and named templates could do exactly the same
thing (as it would be if you had 'sequence constructors' rather than
'content constructors') then you could get away with not introducing
xsl:function and instead allowing templates to be called through
function calls (as Jim thought)... it's an idea.

>> If a user wanted to override saxon:evaluate() with their own
>> function named saxon:evaluate(), i think an error should be thrown.
>
> That would imply that if the user writes an emulation of
> saxon:evaluate in order to allow a stylesheet written for Saxon to
> run under (say) Sablotron, then the stylesheet containing this
> emulation will fail when it's run under Saxon.
>
> The alternatives: choosing the vendor's version of saxon:evaluate()
> in preference to the user's version means that the stylesheet may
> produce different results when run under different processors. In
> theory, a vendor could return anything he liked in response to any
> extension function call by arguing that he was calling his own
> implementation (sounds perverse, but these things happen when it
> comes to running benchmarks and conformance tests). Choosing the
> user's version in preference means that instead of emulating
> saxon:evaluate(), the user would have to write a wrapper function
> that makes the decision whether to call user code or to call the
> vendor's version. This to me seems the cleanest solution.

I'm not sure how that would work. How could a user write a wrapper
saxon:evaluate() function in which it called the native
saxon:evaluate() function? If they'd have to use different names to do
it, then you may as well make it so that the vendor implementation
wins, and if the user wants to avoid a particular vendor's
implementation from being called *then* they have to write a wrapper
function with a different name.

> We decided administratively that since XSLT is concerned with
> producing human-readable output, and XQuery isn't, we would handle
> this [date formatting] requirement within the XSL WG for the moment,
> and then consider moving the solution into the shared function
> library later. But the solution is likely to be a simple function
> that can be called from XPath expressions.

Cool :) I'm looking forward to that. Are there likely to be number and
date *parsing* functions as well?

> Perhaps you are assuming that because these elements assign a URI to
> the result tree, the result tree must be stored on disk and
> therefore must be serialized? That's an incorrect assumption. The
> idea is that the URI can be used (by some implementation-defined
> API) to locate the result tree in memory. Unlike the XSLT 1.1
> facility, and many current implementations, the idea is that the
> processor should be able to produce multiple result trees even if it
> doesn't support serialization.
[snip]
> One candidate for a separate conformance module is serialization.
> Instead of making the whole serialization spec use the word "should"
> rather than "must", it would be better to say that implementations
> can choose whether to implement serialization, but if they do, they
> must implement it as described.

I think that's a neat idea. Presumably a system property would let the
user know whether the implementation supported serialization or not
(and therefore whether they can use disable-output-escaping hacks)?

> Another possible candidate is evaluate(), if we decide to include
> that.

I'd certainly prefer it was included as an option than not included at
all.

>> I am glad that the language binding has been recognized as a
>> different kettle of fish and requires a seperate spec.... has this
>> WG been formed yet?
>
> No, I don't think anyone is actively pursuing this. I'd personally
> like to see a Java binding in a future version of JAXP. The binding
> for 2.0 is going to be considerably more complex than the 1.1
> binding because of the increase in the number of data types.

The one thing that confuses me here is that there's a difference
between defining the *language binding* that's used to define an
extension function and defining the availability of an extension
function. I can see the need for defining language bindings somewhere
else, but what's wrong with defining how extension functions are
brought into a stylesheet within XSLT 2.0?

I'm worried that we'll get into a situation where Saxon and Xalan (for
example) use exactly the same binding for their Java functions *but*
you have to point to the code that defines these extension functions
in different ways in each implementation.

Wouldn't it be possible to define an xsl:script element that had a
QName language attribute to point to the language binding? At least
then if 2 implementations use the same binding, they can recognise the
same QName and we can use the same xsl:script to point to both of
them? That would make a lot more sense than having msxsl:script,
saxon:script and xalan:component/xalan:script all doing basically the
same thing in slightly different ways.

(One option would be to have the default for the language attribute be
'xslt' and then put the xsl:function elements within the xsl:script
element, to give a kind of consistency about how extension functions
are defined.)

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread