[Xpath-ng] xpath-ng requirements

[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.
So an expression should default to for any if no explicit operator is
found? I'm willing to vote yea on that.

 

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

When we talk about function libraries I wonder if there shouldn't be
some way of using a range of exslt functions as basic functions. 


>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).
Fine as long as the areas of failure are such ones as are very seldomly
encountered, the earlier discussion about the namespace axis being one
such, it does us no good if backwards compatibility gets broken only one
or two cases, but it turns out that those are cases that nearly every
xpath user of more advancement then //book will use. Not suggesting that
you would advocate breaking backward compatibility in such a way, only
saying that this is the line between useful backward compatibility and
useful backwards incompatibility( backwards incompatibility due to a
useful extension of the language).


>> 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.

Okay so when you say arbitrary expressions you don't just mean the union
examples from this req. but also stuff like(from W3C examples)
document("otherdoc.xml")/key("x","foo")/a/b

That would be an acceptable thing I suppose. One thing I find amusing
about the concept of XPath-NG or XPath 2.0 for that matter is that many
paths which failed in Xpath 1.0 should prove to be forward compatible.
 

>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.

I voiced complaints against conditional expressions more completely when
the group first began, first I dislike them because I suppose that if I
were working in a language with which I am not extremely comfortable I
would probably be tempted to put such logic as exemplified by conditions
into the language with which I am comfortable thereby causing those who
come after, such as might be expected to have their language preferences
reversed, to have debugging problems.
	 The other debugging problem is that it has been my observation
that many problems in comprehension for people with xslt has not so much
had with xslt to do, as it has with extremely knotty xpaths to do, I do
not suppose that conditionality will make the xpaths more knotty but
rather that people will have two places to look at to try and determine
"why is my template not selecting anything?" There is an already
intrinsic conditionality in parts of xpath 1.0, not() for example, and I
notice that people often have a hard time getting their heads around
if="not(someLongexpressionHere)".



>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.

See my question about exslt functions above.


>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.

Well the latter seems simpler to me, and comprehensible. Can you send me
a quick syntax example so I can see what you're getting at.