Lists Home |
Date Index |
> I don't know how representative it is, but there is also at least
> one person (me) who has started to read these specs, seen that he
> didn't agree with the requirements and didn't consider that the
> addded complexity over XPath 1.0 is not worth the pain IHO and just
> can't comment because he has no comments except "I'll stay with
> XPath 1.0 and exslt as much as I can"...
Which of the requirements don't you agree with? Do you have
requirements that aren't or can't be met using extensions to XPath 1.0
(e.g. for conditional expressions in XPath)? In other words, are you
saying that you don't think that XPath 2.0 is a good idea full stop
(period), or are you saying that *this* XPath 2.0 isn't a good idea?
If it's the latter, then I think you've got a really good comment
right there: "I was hoping that XPath 2.0 would meet my requirement to
A, B and C but the complexity of XPath 2.0 means that the pain's not
worth the gain. XPath 2.0 could be made simpler in order to satisfy my
requirements without causing me pain by X, Y and Z."
I guess voting with your feet is OK, but that's what I meant about
drawing the analogy with XLink. 2 or 3 years down the line we might
realise that actually we did need some of the stuff that XPath 2.0
does, but we're not using it because it's not designed in the way we
needed it to be.
Another thing we could try is to have a switch that makes XSLT 2.0 use
XPath 1.0. XSLT 2.0 has some really useful stuff (multiple output
documents, grouping, result-tree-fragments out the window,
user-defined functions) so it'd be a real shame if we couldn't use
them just because we wanted to avoid XPath 2.0.