[Xpath-ng] xpath-ng requirements

[David Rosenborg]

Hi Bryan,

> 1.3 Must Support Explicit "For Any" or "For All" Comparison and Equality
> Semantics 
> I am conflicted about this.

I think it's reasonable to have this. I think the implicit for-any semantics of
the relational operators of XPath 1.0 are a bit too secret. I'm not
sure we should break backwards compatibility, but I think at least we should
add explicit operators so that future expressions can be clearer.

> 
>   1.4 Must Extend Set of Aggregation Functions 
> Yes. Min() and Max() are mentioned. Definitely, I would like to see
> better possibilities for calculation in XPATH-NG. A log function would
> be nice, and a round() just off the top of my head. Basically I want to
> be able to do calculation, generation of SVG easily in XSLT. With the
> understanding of course that different folks mean different things by
> easily. 

I think trigonometry functions and alike could be put in a math function library.

> 
> 1.5 Should Maintain Backwards Compatibility with XPath 1.0 
> 
> David Rosenborg said something like he wanted backwards compatibility to
> be at 99.4 %, which I take to mean that it should be possible for me to
> switch approximately 99 out of a hundred stylesheets to an application
> using XPATH-NG and suffer no ill-effects. 

I think that we should aim for backwards compatibility, but I also think
it's inevitable that we will miss that target to some degree. Where
possible, changes in semantics should be reflected in syntax so that
incompatible XPath 1.0 expression will fail independently of the
runtime context (instead of starting to behave strange for some
input documents and not others).

> 1.7 Should Support Unary Plus Operator 
> 
> I don't know if I care for this, I think that it might be better if one
> could define specialized types of numbers. Jeni talked about having the
> possibility of scientific notation, maybe there could be some overarcing
> way of handling all non-regulary numerical types. 

I don't have strong feelings about how this is achieved, but in the end
it would be good if +17 is allowed at least for symetry.

> 2 Must Improve Ease of Use 
> 
> Hmm, time was I would have indulged in sarcasm at this point.

:-)

> 2.1 Must Loosen Restrictions on Location Steps 
> 
> talks about allowing unions in location paths, I am for this part. Not
> so sure about the xpointer and node-set functions examples.

Yes, I think we should allow arbitrary expressions as path steps.

> 2.2 Must Provide a Conditional Expression 
> 
> There seems to be people who are for this, and those who are against it
> as the languages which embed xpath-ng will have their own conditional
> expressions. I am against. When I first read of it I thought it was a
> cool idea, later after thinking about it I changed my mind, questions
> about debugging coming uppermost. I've only ever felt the need for a
> conditional expression in my XPath once ...

I think this one depends a lot on what other features the language has.
If the language has the ability of defining functions (which I will propose
at least as a separate module) a conditional expression is a must.
Also if you have some sort of iteration construct like a for-expression,
a conditional expression is important. Otherwise I agree that a
conditional construct is less important.

But I don't see a strong connection between the need for debugging and the
conditional expression specifically. It's quite possible to write hairy expressions
without a conditional expression. In fact, I think some expression can
be written simpler using a conditional expression. So the conditional
expression makes no difference in that matter.

> A propos the XSLT-NG idea, if there were an XSLT-NG then I think these
> functions should be supported in XSLT-NG, which is why I have left them
> off the XPATH-NG list.
> XSLT-NG additional string functions:
> 
> String-pad-beginning() 
> String-pad-ending()
> String-pad() - maybe should be called string-pad-count()
> Replace(string1,regex)

I'd rather put them in a separate function library. I think that XSLT-NG should define
as few functions as possible. The XSLT-NG spec could instead mandate a specific minimum
profile of XPath NG, and a minimum set of function libraries.

> 4.4 Should Add List Data Type to the Type System of the Expression
> Language 
> 
> David Rosenborg has been discussing being able to select against lists,
> am wondering David if your suggestions on this matter are in reference
> to this section?

The lists I propose are more generic. They can for example have
arbitrary values as item, including lists, whereas the XPath 2.0 requirement
only talks about simple-typed values as items.

Cheers,
David