[Xpath-ng] RE: thoughts on work products

[bryan]

Jeni wrote:

>The problem as I see it: XPath should be something that's usable in
>multiple different contexts -- in XSLT, in XQuery, in schema languages,
in >XForms, in XPointer, in DOM, etc. etc. etc.

The problem I worry about is a features creep maybe added in because the
person who thought of it used XPath in the context of a language for
which that feature was extremely beneficial, not considering that it
might be in fact detrimental in other contexts. I know a lot of people
are fans of the ability to use if, for constructs in XPath 2.0, I'm not
for the reason that in my usages of XPath 1.0 I am nearly always using
it in a context, for example a programming language, where one has one's
own if, for constructs and therefore I worry that various forms of
strengthening the language will make for debugging problems in
programming languages, of course if it becomes more and more complex,
and more like an embedded programming language in itself, expertise in
it will become first a valuable addition to the CV and later a necessary
addition. 


Having said the above, I would be happy to accept an XPath NG with
stronger selection capabilities such as if and for, just as I would have
been happy to accept them for XPath 2.0, if one could get rid of the
obnoxious schema stuff. 

A propos David Carlisle's question:

 "One question that I think also needs to be answered is, is the idea to
come up with something that will enable the WG members (such as
Jeni:-) to see the error of their ways and adopt XPath NG as XPath2, and
specifically use it in XSLT 2, or is the assumption that Xpath2 is a
done deal and XPath NG would be an alternative, separate, selection
language"

->I sort of think that it would be nice to design it with the intention
that it would achieve the former, in which case the strategic thing does
not seem to me to define what are the neat new things should be done,
much as I think that could surely result in lots of cool ideas, but
rather to take the XPath 2.0 spec and prune it of the most annoying
things, as a way of stating "this is what we would compromise on" or
"lets just go with this and think about other things later". If that
seems reasonable it might be good if people said something like "such
and such really needs to be cut from XPath 2.0"

I also think that kind of strategy, if explained concisely to the
community might have more beneficial aspects such as adoption of the
alternative.