[Xpath-ng] xpath-ng requirements

[David Rosenborg]

Hi Bryan,

(Your latest post was off-list, as I believe it was unintentional
I'll reply to the the list anyway.)


> >namespace math = "http://xpathng.org/ns/math"
> >import math:*
> Yeah, I saw that, didn't connect it specifically with exslt.
> ...
> I feel somewhat uncomfortable with it in XPath NG as well, but on the
> other hand if it were XSLT-NG there should be, I suppose, ways of
> handling (xpath)fallbacks etc. in the XSLT syntax. So I can't say I feel
> that comfortable with it there,

I'm not sure I follow you here. The sole purpose of the import
facility is to bring functions into the unprefixed world. I don't
see how fallbacks fit into that picture.
As it is now, ther's a one to one mapping between what's
considered a core function and what can be used without a prefix.
I think these are actually orthogonal aspects. Functions
should be selected for the core function library based on their
general applicability and not the fact that you wan't to use them
without prefixes. The set of functions that a particular user
wants to use without prefixes can be much larger than
the set of functions blessed for the core library.

> the goal I think should be to present a
> much simpler structure, yet with a marked increase in expressive power
> from the current XPath 1.0,  than that currently coming out of W3C, if
> we come up with something as complex then I think XPath NG loses.

Yes, simpler and more intuitive but not necessarily by doing smaller
or less complex things even if that's good. I think the main
difference should be in focus: instead on focusing on how we can tangle
everything up in XML Schema, we should focus on modularity, abstraction and
general applicability. And therefore we will get a more versatile, extensible
and
less monolithic language as a result.

> >Well, I believe that conditional expressions are about the least
> complex
> >thing we are discussing for inclusion in XPath NG.
>
> Good, I'm glad I've won you over to the side of getting rid of
> conditional expressions because by doing so one can cut down on
> complexity. Because after all:
>
>  2 Must Improve Ease of Use
>

Ehr, no, on the contrary, I think a conditional expressions is important
and that it improves the ease of use.

Cheers,
David