RE: Alternative StepExpr evaluation policy

Michael,

>Interesting suggestions. I'm not sure there's much enthusiasm for
adding such features at >this stage, and there will probably be a
feeling in some quarters that overloading the >"/" operator to this
extent is undesirable. In principle I think the ideas are technically
>feasible; subject to some comments below.

Thanks.


>You need to take into account that E2 is evaluated once for each node
in E1. In principle, some evaluations >can return a number and others
return a node, for example:
>E1/(if (position()=1) then 42 else *) 
>So the detailed rules are likely to be a bit complicated. 

Ok, granted, my suggestions do come from my perspective as a purist in
that I don't like the idea of branching instructions in what I prefer to
think of as a single line language. That is, im assuming the feature set
of Xpath that is most commonly used in XSLT and simillar applications.

Regardless of this, the evaluation of the above statement would still
work with the rules that I have suggested, especially since E1 is a
nodeset, and the expression in E2 must also be a nodeset by current
Xpath 2.0 standards otherwise a type error will be thrown.

By way of tangenting, if you are going to use branching instructions in
a single line Xpath statement why not considder using the trinary
conditional expression notation used in languages like C++

i.e.

condition ? true-val : false-val 


>> If E2 evaluates to a literal result then the expression 
>> should be evaluated as; 
>> 
>> E1/child::T2 
>
>By "literal result" I guess you mean a string? You need to explain how
the string is converted to a QName,
>i.e. how namespaces are handled. And the same considerations apply as
for a numeric value.

Namespaces would be handled as with any normal node test, i.e. if the
name matches a Qname, or NCName the
Relevant action is taken by the processor.

Numeric values can be easily detected with a call to the Number()
function, and as necessary converted to the child node number as
described previously i.e. "child::*[T2]"


>I think you can't easily package all of these effects into one
expression at once, but the individual capabilities
>are already there, using the constructs:
>E1/*[$number] 
>E1/*[name()=$string] 
>E1/*[$boolean] 

Not exactly, the expression I described provides a context free method
of optionally selecting all child nodes i.e "E1/*". By using the
predicate expression you have described above, the context will change
with respect to the evaluation of the expression returning the boolean
result.

>So I don't think you're proposing any important new capability, just a
bit of shorthand syntax. 

I prefer to think of it as intelligent type casting and exception
handling.

Received on Tuesday, 16 September 2003 12:33:27 UTC