Re: [SCXML] Incorrect XPath expressions in IR tests 153 & 155

Hi Zjnue,


On 2015-02-09 19:28, Zjnue Brzavi wrote:
> Hi Ate,
>
>        <datamodel>
>          <data id="Var1" expr="0"/>
>          <data id="Var2"/>
>          <data id="Var3">
>            <node xmlns="">1</node><node xmlns="">2</node><node xmlns="">3</node>
>          </data>
>          <data id="Var4" expr="1"/>
>        </datamodel>
>
> [..]
>
>     The "Var2/text()" xpath expressions in the if condition check and the
>     assignment value expression above are not valid/usable in this context.
>
>     The foreach element will assign each of the Var3 <node>x</node> children to
>     the Var2 variable, and the Var2 variable (its data node) thus will contains
>     no (direct) text node children, only a (single) "node" child.
>
>     To access the actual text value of that "node" child, the expression must
>     be: "$Var2/*/text()" or if desired "$Var2/node[1]/text()".
>
>
> This is something I've implemented also, and on this rare occasion I have to
> disagree with the suggestion.
>
> Let's take this SO post as context:
> http://stackoverflow.com/questions/11744465/xpath-difference-between-node-and-text
>
> Now back to the example you've stated.
> Var3 evaluates to an XMLList, which has this simplified structure:
>
> element node (name="node")
>      text node (value="1")
> element node (name="node")
>      text node (value="2")
> element node (name="node")
>      text node (value="3")
>
> Now, in the foreach structure, as we iterate through this list, we assign a
> reference to the next element node to Var2.
> In turn, $Var2/text() evaluates to 1, 2 and 3 as we expect.
>
> My guess is that your implementation creates a new XML instance when assigning
> values to Var2, giving it values such as:
>
> root node
>      element node (name="node")
>          text node (value="1")
>
> root node
>      element node (name="node")
>          text node (value="2")
>
> and so on, thereby requiring the extra axis specifier as you suggested:
> $Var2/*/text()   OR  $Var2/node[1]/text()
>
> However, as we are dealing with a complex type, I believe it is wrong to create
> new instances and that we should use references to the existing nodes, making
> the tests valid as they are currently specified.
>
> In my implementation, I have a normalized foreach routine for the different
> datamodels:
> https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Interp.hx#L935-L972
>
> This works well for the tests mentioned, when I feed it with an array containing
> references to the different nodes in the XMLList, formed here:
> https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Model.hx#L354-L366
>
> Do you agree?

I agree such a solution was what I also implemented initially.

However I changed my view on it and now implemented an actual item copy 
assignment to the variable <data> node, and even create such a <data> node first 
if it doesn't yet exist (as required and tested by tests 150 and 151).

The reason I changed my implementation is that the wording in the specification 
and the tests made me conclude that the intent is that XPath variables (in 
SCXML) always (must) refer to an actual <data> node with an id equal to the 
variable name.

In the solution you implemented the XPath variable *initially* refers to such a 
<data> node, but then loses its binding/reference to a datamodel <data> node and 
becomes a 'transient' reference to the intermediate array items.

Although I'd also rather and more optimally would like to use the XPath 
variables as transient pointers, the spec wording and IR tests don't seem to 
agree with that.
Your implementation maybe passes each individual tests, but if rules and 
semantics checked in one test should also apply in other tests, then IMO your 
solution no longer is or would be valid.

Note for example that such transient XPath variable no longer will agree to an 
XPath test like "local-name($Var2)=='data' and '$Var2@id='Var2'", something test 
463 is testing. Of course not in the context of a <foreach>, but I assume(d?) 
such XPath variable conditions should always be true.

One thing which seems to be required anyway is that if a <foreach> item or index 
doesn't exist yet, at least a Node element must be created to hold the variable 
data, as for example is checked by tests 150 and 151.

Note also that in test 151 the index variable, which just 'holds' a number, 
still requires creating a Node variable because of the final test condition 
""$Var5/* or $Var5/text()".
A 'normal' XPath variable perfectly well can point to just a number value, 
however the SCXML spec (and/or tests) require even for such variables an actual 
(data) node element.

But, maybe I've been assuming and interpreting too much into this...
Trying to get the xpath datamodel implementation working properly, and as 
intended, has been (and still is) quite a challenge so say the least.

Maybe Jim can chime in and help clarify what the actual or intended requirements 
concerning XPath variables are.

Thanks, Ate

>
> Best regards,
> Zjnue
>

Received on Monday, 9 February 2015 21:20:48 UTC