Re: Re: Re: mapping (Was: Re: Re: . in for)

David wrote:
> well actually for higher order functions (which probably have less
> chance to get in than regexps, as it would require extending the
> data model, so be more of a change for the Working Group) I don't
> think the need at the moment for a worked out proposal, just to
> re-iterate that there is a _requirement_ for the functionality,
> based on 2 years of xpath 1 experience.

I agree with David - I think that the WGs probably need to be
convinced of the requirement before they'll even start to consider
syntax. But I think that it would be best to demonstrate the
requirement rather than simply asserting that it is a requirement, so
I'd include some use cases if you can.

> This is to counter the "nice idea for the future, but not needed for
> Xquery 1" answer which you will probably get. I think XSLT users
> need to be more vocal that two years merging XPath with Xquery only
> to add features needed for Xquery, without adding missing
> functionality shown up by XSLT use is not really what's required of
> a merged Xpath/Xquery language.

Amen... or at least to a certain extent. I think it should be feasible
for XSLT to define additions to XPath, just like other host languages
(e.g. XPointer, XQuery) do. I think it makes more sense for XPath to
be kept to the minimum overlap, and extended, rather than the maximum
overlap and restricted. For example, if the XSL WG were to accept the
argument for higher order functions, they should be allowed to extend
XPath-for-XSLT so that they were included for us XSLT users, without
XQuery having to take them on board. Then when XQuery realise that
they need higher order functions, they can be added to the XPath core.

Cheers,

Jeni

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


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