[
Lists Home |
Date Index |
Thread Index
]
> My argument is that it would be perfectly possible for XSLT
> and XPath 2.0 to work in a complementary way again. We could
> redraw the line where it was before, but allow a couple of
> extra shorthand features in the text-based syntax, namely
> conditional expressions and a simple mapping operator. But
> these should be shorthand features that are used for the most
> common kinds of looping and conditional expressions, not
> mirrors of the full functionality of XSLT.
>
Jeni, as you said in an earlier mail, there is no absolutely correct
place to draw the line. My approach is that XPath is there to calculate
values based on the information in the source tree, while XSLT is there
to construct nodes in the result tree. This isn't the only way of
defining the distinction, but it works for me. Drawing the line here
puts sequence construction firmly on the XPath side of the boundary,
because a sequence is a value. Places where the line has been drawn
differently, for example <xsl:number/>, stick out like a sore thumb.
There are some people (including people on the WG) who would like to
draw it differently, and (I regret to say) there are some who would like
to compromise by duplicating the functionality on both sides. There is
no right answer, but I'm personally happy with having the line where
we've put it. It does mean that some XPath expressions sit rather
uncomfortably inside XML attributes, and we've looked at proposals that
address that, but I don't feel that balancing the length of the XPath
attributes against the number of XSLT elements is the right way to make
the judgement. You can always break up long expressions using variables
or function calls.
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
