Re: [XSLT2.0] value-of and backwards compatibility

Our ref: qt-2004Jan0010-01

Niko,

Sorry for the long delay in responding to this message; this is because the
working group debated the issue several times before coming to a conclusion,
as we recognize the serious implications of the decision.

In the end, having considered various alternatives, we decided to confirm
the status quo as defined in the November 2003 working draft. There were a
number of factors:

* we felt that by default, xsl:value-of and attribute value templates should
produce the same result. In attribute value templates, we do not have the
luxury of a "separator" attribute to switch the behavior.

* in the case where the argument evaluates to a single node and the typed
value of that node is a sequence, we feel that producing the space-separated
atomized value as the result is the right thing to do; it's the effect that
achieves the best compatibility between schema-aware and non-schema aware
processors, and it is also consistent with what XQuery does.

* treating a sequence of several nodes each containing one atomic value
differently from a single node containing a sequence of atomic values would
be messily different from the way other constructs in the language behave.

* the backwards compatibility problem is manageable. There will be some
cases where users have to take action, for example where they have written
<xsl:value-of select="following-sibling::*"/>, but it will be fairly evident
in these cases what has gone wrong, and the fix, of inserting the predicate
[1], is not difficult. It is also not difficult for tools to assist in this.

* the potential for performance problems with constructs like <xsl:value-of
select="//title"/> is real, but it is no different from any other situation
where first item semantics have been changed (usually to an error). We think
that vendors will be able to find strategies to tackle this problem, either
by static optimization techniques, or by transition tools and services.

The arguments here are finely balanced but we feel that we have a better
language design for the future by this decision, and that this outweighs the
transition problems that the decision will cause.

Thanks for raising this important question, and feel free to respond if you
feel we have not addressed your concerns adequately.

Regards,

Michael Kay
for the XSL Working Group

Received on Thursday, 24 June 2004 09:23:51 UTC