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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
Hi,

I think I detected the following incorrect XPath expression in IR test 153

The scxml test document generated by the confXPath.xsl stylesheet contains the
following datamodel:

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

and the following <foreach> element:

   <foreach item="Var2" array="$Var3/*">
     <if cond="$Var1/text() &lt;$Var2/text() ">
       <assign location="$Var1" expr="$Var2/text()"/>
     <else/>
       <!-- values are out of order, record failure -->
       <assign location="$Var4" expr="0"/>
     </if>
   </foreach>

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()".


And IMO a similar incorrect xpath expression, although produced differently and
in different context, exists in test 155 where:

   expr="$Var1/text() + $Var2/text()"

should be:

   expr="$Var1/text() + $Var2/*/text()"
or
   expr="$Var1/text() + $Var2/node[1]/text()"

to produce the correct result.


Thanks, Ate

Reply | Threaded
Open this post in threaded view
|

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

Jim Barnett
Ate,
  Thanks for noticing this.  I will look into it.

- Jim
On 2/8/2015 5:22 PM, Ate Douma wrote:

> Hi,
>
> I think I detected the following incorrect XPath expression in IR test
> 153
>
> The scxml test document generated by the confXPath.xsl stylesheet
> contains the following datamodel:
>
>   <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>
>
> and the following <foreach> element:
>
>   <foreach item="Var2" array="$Var3/*">
>     <if cond="$Var1/text() &lt;$Var2/text() ">
>       <assign location="$Var1" expr="$Var2/text()"/>
>     <else/>
>       <!-- values are out of order, record failure -->
>       <assign location="$Var4" expr="0"/>
>     </if>
>   </foreach>
>
> 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()".
>
>
> And IMO a similar incorrect xpath expression, although produced
> differently and in different context, exists in test 155 where:
>
>   expr="$Var1/text() + $Var2/text()"
>
> should be:
>
>   expr="$Var1/text() + $Var2/*/text()"
> or
>   expr="$Var1/text() + $Var2/node[1]/text()"
>
> to produce the correct result.
>
>
> Thanks, Ate
>


Reply | Threaded
Open this post in threaded view
|

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

Zjnue Brzavi
In reply to this post by Ate Douma
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.

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?

Best regards,
Zjnue

Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
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
>


Reply | Threaded
Open this post in threaded view
|

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

Jim Barnett
Ate,
  Questions about the XPath datamodel are always tricky, because the group's XPath experts haven't participated in several years.  ( I'm certainly not an XPath expert.)  However as I recall our past discussions of this issue, the consensus was with Zjnue's interpretation.  Specifically, the requirement for the creation of a <data> node holds for top-level <data> elements only.  Furthermore, the intent was that <foreach> would have what you call 'transient pointers' to the array elements.  In particular, we intended that modifications to those array elements in the course of <foreach> would remain in effect after the <foreach> terminated.  Specifically, when we say "The SCXML processor MUST act as if it has made a shallow copy of the collection produced by the evaluation of 'array'" the intent was that _only_ a  shallow copy be made and that it be possible to access the array elements directly.     

Tests 150 and 151 use the same list as tests 153 and 155.  (The .txml file has <conf:array123> and the xslt transform produces the <node> elements.)  So I would expect all 4 tests to work the same way, with the XPath variable bound to the <node> elements in turn.  150 and 151 do not test that the newly created variable is initially bound to a <data> element.  (Actually, all tests 150 and 151 do is check that using a <foreach> with a previously undeclared variable does not raise an error.  The tests are rather bogus because the <foreach> doesn't do anything, but I was trying to keep the test simple and avoid extra logic that might introduce subtle errors.) 

 As for test 463, it is explicitly testing the structure of a variable created by the <data> element.  I don't think it is required that _any_ XPath variable that occurs in an SCXML document have that structure.  I admit that this leaves open the question of what structure such other variables should have. As the spec stands, it is implementation-specific.  However, we did intend for the behavior inside <foreach> to be what Zjnue describes.   

I'm willing to be persuaded that we're wrong, though.  It may well be that our intended interpretation causes problems that we did not foresee. 

- Jim
P.S. Everyone who has worked with the XPath data model has had problems with it. 



On 2/9/2015 4:20 PM, Ate Douma wrote:
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




Reply | Threaded
Open this post in threaded view
|

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

Zjnue Brzavi
Hi Ate and Jim,

Firstly, apologies as I've been mistaken regarding test 153. My implementation only tested the XPath specific tests, as are listed here:
https://github.com/zjnue/hscxml/commit/6d0d7318ca847f876d7755da8633c92c022a4766

Secondly, I do remember now making a workaround when setting an XML variable.
While defining variables the normal <data id"varname">...</data> way, I've had to change that strategy when the value passed in was already of type XML (used in my implementation for foreach cases only I think): https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Model.hx#L426-L429

This I believe makes test483 pass, which contains a foreach.

On the whole I don't mind admitting that I've tried to take shortest paths with my XPath datamodel implementation, as I've not had the time for it and the sole purpose of the effort was simply to help the spec proceed to next stages. I completely agree that this datamodel has been quite a challenge, let alone finding a solid XPath library.
Given these considerations and that my implementation has only concerned itself with a small subset of the test suite, it is not well placed to make any claims, although it does already offer a fair bit of functionality.

Happy to hear how these matters conclude and all my respect goes to those persisting with it.

Best wishes,
Zjnue


On Mon, Feb 9, 2015 at 11:17 PM, Jim Barnett <[hidden email]> wrote:
Ate,
  Questions about the XPath datamodel are always tricky, because the group's XPath experts haven't participated in several years.  ( I'm certainly not an XPath expert.)  However as I recall our past discussions of this issue, the consensus was with Zjnue's interpretation.  Specifically, the requirement for the creation of a <data> node holds for top-level <data> elements only.  Furthermore, the intent was that <foreach> would have what you call 'transient pointers' to the array elements.  In particular, we intended that modifications to those array elements in the course of <foreach> would remain in effect after the <foreach> terminated.  Specifically, when we say "The SCXML processor MUST act as if it has made a shallow copy of the collection produced by the evaluation of 'array'" the intent was that _only_ a  shallow copy be made and that it be possible to access the array elements directly.     

Tests 150 and 151 use the same list as tests 153 and 155.  (The .txml file has <conf:array123> and the xslt transform produces the <node> elements.)  So I would expect all 4 tests to work the same way, with the XPath variable bound to the <node> elements in turn.  150 and 151 do not test that the newly created variable is initially bound to a <data> element.  (Actually, all tests 150 and 151 do is check that using a <foreach> with a previously undeclared variable does not raise an error.  The tests are rather bogus because the <foreach> doesn't do anything, but I was trying to keep the test simple and avoid extra logic that might introduce subtle errors.) 

 As for test 463, it is explicitly testing the structure of a variable created by the <data> element.  I don't think it is required that _any_ XPath variable that occurs in an SCXML document have that structure.  I admit that this leaves open the question of what structure such other variables should have. As the spec stands, it is implementation-specific.  However, we did intend for the behavior inside <foreach> to be what Zjnue describes.   

I'm willing to be persuaded that we're wrong, though.  It may well be that our intended interpretation causes problems that we did not foresee. 

- Jim
P.S. Everyone who has worked with the XPath data model has had problems with it. 



On 2/9/2015 4:20 PM, Ate Douma wrote:
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





Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
In reply to this post by Jim Barnett
Hi Jim, thanks for the thorough explanation below.

However, I'm still not completely convinced of this interpretation, which IMO
should be part of the spec, to allow it to be formally validated/confirmed.

More comments inline below.

On 2015-02-09 23:17, Jim Barnett wrote:
> Ate,
>    Questions about the XPath datamodel are always tricky, because the group's
> XPath experts haven't participated in several years.  ( I'm certainly not an
> XPath expert.)  However as I recall our past discussions of this issue, the
> consensus was with Zjnue's interpretation.  Specifically, the requirement for
> the creation of a <data> node holds for top-level <data> elements only.
This I find odd, and doesn't seem to agree with the statements made in section
B.3.1, which says:
   "For each <data> element in the document the SCXML Processor *must* create a
    child of <datamodel> called <data> [...]"
and:
   "The Processor *must* also bind an XPath variable of the same name to that
    datamodel <data> element."

> Furthermore, the intent was that <foreach> would have what you call 'transient
> pointers' to the array elements.  In particular, we intended that modifications
> to those array elements in the course of <foreach> would remain in effect after
> the <foreach> terminated.  Specifically, when we say "The SCXML processor /MUST/
> act as if it has made a shallow copy of the collection produced by the
> evaluation of 'array'" the intent was that _only_ a  shallow copy be made and
> that it be possible to access the array elements directly.
This maybe better be further clarified in the specification as well then?

>
> Tests 150 and 151 use the same list as tests 153 and 155.  (The .txml file has
> <conf:array123> and the xslt transform produces the <node> elements.)  So I
> would expect all 4 tests to work the same way, with the XPath variable bound to
> the <node> elements in turn.  150 and 151 do not test that the newly created
> variable is initially bound to a <data> element.  (Actually, all tests 150 and
> 151 do is check that using a <foreach> with a previously undeclared variable
> does not raise an error.  The tests are rather bogus because the <foreach>
> doesn't do anything, but I was trying to keep the test simple and avoid extra
> logic that might introduce subtle errors.)

Alright, I can see that.
But for example the Var5 'index' variable in test 151, does that really require
to hold/store its value in a Node element, as currently the test requires?
An XPath variable just as well can just hold a number (as I initially
implemented it), but that would fail the test as it is right now.

>
>   As for test 463, it is explicitly testing the structure of a variable created
> by the <data> element.  I don't think it is required that _any_ XPath variable
> that occurs in an SCXML document have that structure.  I admit that this leaves
> open the question of what structure such other variables should have. As the
> spec stands, it is implementation-specific.  However, we did intend for the
> behavior inside <foreach> to be what Zjnue describes.

What I'm wondering about is why there is this required to define a <data>
element in the first place. I assume there is (was) a good and explicit reason
for it.
The only argument I could come up with was that it is used/needed for
data communication, ensuring a predefined 'container' <data> node.
But if that argument is correct, *then* it doesn't make sense to NOT require
this throughout all xpath data model accessors, including the variables, as
otherwise this whole 'assurance' would break, depending on which xpath variable
could/might have been 'broken' this 'contract' because of some intermediate
<foreach> usage somewhere. Especially for xpath variables which *initially* were
initialized/binded to a 'top level' <data> element.

Anyway, this of course all is speculation and interpretation my side.
As you said: the xpath data model definitely is causing a lot of problems.

And just FYI (and I already informed Jim about this), I've decided earlier
today to cancel my attempt to implement and complete the xpath data model for
Apache Commons SCXML.
Not all of a sudden or because of the current topic we're discussing, but
because it just turns out too much trouble getting it right, for very little
actual gain/usage. That is: in the case of Apache Commmons SCXML.

Instead, I'll focus now on the proper implementation and completion of the
SCXML specification for our primary supported languages Jexl and Groovy.
We have little/no real demand for the 'pure' xpath data model as defined by the
specification.
However, XML/XPath data usage from *within* Jexl/Groovy very much make sense,
and this is what Apache Commons SCXML already supports and will continue to do.
And that requires a lot less headache :)

Thanks,
Ate

>
> I'm willing to be persuaded that we're wrong, though.  It may well be that our
> intended interpretation causes problems that we did not foresee.
>
> - Jim
> P.S. Everyone who has worked with the XPath data model has had problems with it.
>
>
>
> On 2/9/2015 4:20 PM, Ate Douma wrote:
>> 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
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
On 2015-02-10 00:33, Ate Douma wrote:

> Hi Jim, thanks for the thorough explanation below.
>
> However, I'm still not completely convinced of this interpretation, which IMO
> should be part of the spec, to allow it to be formally validated/confirmed.
>
> More comments inline below.
>
> On 2015-02-09 23:17, Jim Barnett wrote:
>> Ate,
>>    Questions about the XPath datamodel are always tricky, because the group's
>> XPath experts haven't participated in several years.  ( I'm certainly not an
>> XPath expert.)  However as I recall our past discussions of this issue, the
>> consensus was with Zjnue's interpretation.  Specifically, the requirement for
>> the creation of a <data> node holds for top-level <data> elements only.
> This I find odd, and doesn't seem to agree with the statements made in section
> B.3.1, which says:
>    "For each <data> element in the document the SCXML Processor *must* create a
>     child of <datamodel> called <data> [...]"
> and:
>    "The Processor *must* also bind an XPath variable of the same name to that
>     datamodel <data> element."
>
>> Furthermore, the intent was that <foreach> would have what you call 'transient
>> pointers' to the array elements.  In particular, we intended that modifications
>> to those array elements in the course of <foreach> would remain in effect after
>> the <foreach> terminated.  Specifically, when we say "The SCXML processor /MUST/
>> act as if it has made a shallow copy of the collection produced by the
>> evaluation of 'array'" the intent was that _only_ a  shallow copy be made and
>> that it be possible to access the array elements directly.
> This maybe better be further clarified in the specification as well then?
>
>>
>> Tests 150 and 151 use the same list as tests 153 and 155.  (The .txml file has
>> <conf:array123> and the xslt transform produces the <node> elements.)  So I
>> would expect all 4 tests to work the same way, with the XPath variable bound to
>> the <node> elements in turn.  150 and 151 do not test that the newly created
>> variable is initially bound to a <data> element.  (Actually, all tests 150 and
>> 151 do is check that using a <foreach> with a previously undeclared variable
>> does not raise an error.  The tests are rather bogus because the <foreach>
>> doesn't do anything, but I was trying to keep the test simple and avoid extra
>> logic that might introduce subtle errors.)
>
> Alright, I can see that.
> But for example the Var5 'index' variable in test 151, does that really require
> to hold/store its value in a Node element, as currently the test requires?
> An XPath variable just as well can just hold a number (as I initially
> implemented it), but that would fail the test as it is right now.
>
>>
>>   As for test 463, it is explicitly testing the structure of a variable created
>> by the <data> element.  I don't think it is required that _any_ XPath variable
>> that occurs in an SCXML document have that structure.  I admit that this leaves
>> open the question of what structure such other variables should have. As the
>> spec stands, it is implementation-specific.  However, we did intend for the
>> behavior inside <foreach> to be what Zjnue describes.
>
> What I'm wondering about is why there is this required to define a <data>
> element in the first place. I assume there is (was) a good and explicit reason
> for it.
> The only argument I could come up with was that it is used/needed for
> data communication, ensuring a predefined 'container' <data> node.
> But if that argument is correct, *then* it doesn't make sense to NOT require
> this throughout all xpath data model accessors, including the variables, as
> otherwise this whole 'assurance' would break, depending on which xpath variable
> could/might have been 'broken' this 'contract' because of some intermediate
> <foreach> usage somewhere. Especially for xpath variables which *initially* were
> initialized/binded to a 'top level' <data> element.

Maybe I can better explain my thoughts on this through an example.
If we would 'combine' an 'transient' xpath item variable with test 176, like this:

   <datamodel>
     <data id="Var1" expr="1"/>
     <data id="Var2"/>
     <data id="Var3">
       <node xmlns="">1</node><node xmlns="">2</node><node xmlns="">3</node>
     </data>
   </datamodel>

   <state id="s0">
     <onentry>
      <!-- some fake <foreach/>, resulting in a transient $Var1 'pointing' at
           <node>3</node> -->
      <foreach item="Var1" index="Var2" array="$Var3/*"/>
      <send event="event1">
        <param name="aParam" expr="$Var1/text()"/>
      </send>
     </onentry>

     <transition event="event1" target="s1">
       <!-- this now no longer will be valid, as in test 176 -->
       <assign location="$Var2" expr="$_event/data/data[@id='aParam']/text()"/>
     </transition>
     ...
  </state>

<ust it be assumed that the assign value expression in the transition on
"event1" must 'know' the param value "$Var1/text()" was no
longer a <data> pointer but a transient pointer instead, as 'side-effect' of
the <foreach> loop?


>
> Anyway, this of course all is speculation and interpretation my side.
> As you said: the xpath data model definitely is causing a lot of problems.
>
> And just FYI (and I already informed Jim about this), I've decided earlier
> today to cancel my attempt to implement and complete the xpath data model for
> Apache Commons SCXML.
> Not all of a sudden or because of the current topic we're discussing, but
> because it just turns out too much trouble getting it right, for very little
> actual gain/usage. That is: in the case of Apache Commmons SCXML.
>
> Instead, I'll focus now on the proper implementation and completion of the
> SCXML specification for our primary supported languages Jexl and Groovy.
> We have little/no real demand for the 'pure' xpath data model as defined by the
> specification.
> However, XML/XPath data usage from *within* Jexl/Groovy very much make sense,
> and this is what Apache Commons SCXML already supports and will continue to do.
> And that requires a lot less headache :)
>
> Thanks,
> Ate
>
>>
>> I'm willing to be persuaded that we're wrong, though.  It may well be that our
>> intended interpretation causes problems that we did not foresee.
>>
>> - Jim
>> P.S. Everyone who has worked with the XPath data model has had problems with it.
>>
>>
>>
>> On 2/9/2015 4:20 PM, Ate Douma wrote:
>>> 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
>>>>
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Ate Douma
On 2015-02-10 01:02, Ate Douma wrote:

> On 2015-02-10 00:33, Ate Douma wrote:
>> Hi Jim, thanks for the thorough explanation below.
>>
>> However, I'm still not completely convinced of this interpretation, which IMO
>> should be part of the spec, to allow it to be formally validated/confirmed.
>>
>> More comments inline below.
>>
>> On 2015-02-09 23:17, Jim Barnett wrote:
>>> Ate,
>>>    Questions about the XPath datamodel are always tricky, because the group's
>>> XPath experts haven't participated in several years.  ( I'm certainly not an
>>> XPath expert.)  However as I recall our past discussions of this issue, the
>>> consensus was with Zjnue's interpretation.  Specifically, the requirement for
>>> the creation of a <data> node holds for top-level <data> elements only.
>> This I find odd, and doesn't seem to agree with the statements made in section
>> B.3.1, which says:
>>    "For each <data> element in the document the SCXML Processor *must* create a
>>     child of <datamodel> called <data> [...]"
>> and:
>>    "The Processor *must* also bind an XPath variable of the same name to that
>>     datamodel <data> element."
>>
>>> Furthermore, the intent was that <foreach> would have what you call 'transient
>>> pointers' to the array elements.  In particular, we intended that modifications
>>> to those array elements in the course of <foreach> would remain in effect after
>>> the <foreach> terminated.  Specifically, when we say "The SCXML processor /MUST/
>>> act as if it has made a shallow copy of the collection produced by the
>>> evaluation of 'array'" the intent was that _only_ a  shallow copy be made and
>>> that it be possible to access the array elements directly.
>> This maybe better be further clarified in the specification as well then?
>>
>>>
>>> Tests 150 and 151 use the same list as tests 153 and 155.  (The .txml file has
>>> <conf:array123> and the xslt transform produces the <node> elements.)  So I
>>> would expect all 4 tests to work the same way, with the XPath variable bound to
>>> the <node> elements in turn.  150 and 151 do not test that the newly created
>>> variable is initially bound to a <data> element.  (Actually, all tests 150 and
>>> 151 do is check that using a <foreach> with a previously undeclared variable
>>> does not raise an error.  The tests are rather bogus because the <foreach>
>>> doesn't do anything, but I was trying to keep the test simple and avoid extra
>>> logic that might introduce subtle errors.)
>>
>> Alright, I can see that.
>> But for example the Var5 'index' variable in test 151, does that really require
>> to hold/store its value in a Node element, as currently the test requires?
>> An XPath variable just as well can just hold a number (as I initially
>> implemented it), but that would fail the test as it is right now.
>>
>>>
>>>   As for test 463, it is explicitly testing the structure of a variable created
>>> by the <data> element.  I don't think it is required that _any_ XPath variable
>>> that occurs in an SCXML document have that structure.  I admit that this leaves
>>> open the question of what structure such other variables should have. As the
>>> spec stands, it is implementation-specific.  However, we did intend for the
>>> behavior inside <foreach> to be what Zjnue describes.
>>
>> What I'm wondering about is why there is this required to define a <data>
>> element in the first place. I assume there is (was) a good and explicit reason
>> for it.
>> The only argument I could come up with was that it is used/needed for
>> data communication, ensuring a predefined 'container' <data> node.
>> But if that argument is correct, *then* it doesn't make sense to NOT require
>> this throughout all xpath data model accessors, including the variables, as
>> otherwise this whole 'assurance' would break, depending on which xpath variable
>> could/might have been 'broken' this 'contract' because of some intermediate
>> <foreach> usage somewhere. Especially for xpath variables which *initially* were
>> initialized/binded to a 'top level' <data> element.
>
> Maybe I can better explain my thoughts on this through an example.
> If we would 'combine' an 'transient' xpath item variable with test 176, like this:
>
>    <datamodel>
>      <data id="Var1" expr="1"/>
>      <data id="Var2"/>
>      <data id="Var3">
>        <node xmlns="">1</node><node xmlns="">2</node><node xmlns="">3</node>
>      </data>
>    </datamodel>
>
>    <state id="s0">
>      <onentry>
>       <!-- some fake <foreach/>, resulting in a transient $Var1 'pointing' at
>            <node>3</node> -->
>       <foreach item="Var1" index="Var2" array="$Var3/*"/>
>       <send event="event1">
>         <param name="aParam" expr="$Var1/text()"/>
>       </send>
>      </onentry>
>
>      <transition event="event1" target="s1">
>        <!-- this now no longer will be valid, as in test 176 -->
>        <assign location="$Var2" expr="$_event/data/data[@id='aParam']/text()"/>
>      </transition>
>      ...
>   </state>
>
> <ust it be assumed that the assign value expression in the transition on
> "event1" must 'know' the param value "$Var1/text()" was no
> longer a <data> pointer but a transient pointer instead, as 'side-effect' of
> the <foreach> loop?
>

On second review, scratch this attempt at an example: it is actually incorrect
and thus not properly explaining what I intended.


>
>>
>> Anyway, this of course all is speculation and interpretation my side.
>> As you said: the xpath data model definitely is causing a lot of problems.
>>
>> And just FYI (and I already informed Jim about this), I've decided earlier
>> today to cancel my attempt to implement and complete the xpath data model for
>> Apache Commons SCXML.
>> Not all of a sudden or because of the current topic we're discussing, but
>> because it just turns out too much trouble getting it right, for very little
>> actual gain/usage. That is: in the case of Apache Commmons SCXML.
>>
>> Instead, I'll focus now on the proper implementation and completion of the
>> SCXML specification for our primary supported languages Jexl and Groovy.
>> We have little/no real demand for the 'pure' xpath data model as defined by the
>> specification.
>> However, XML/XPath data usage from *within* Jexl/Groovy very much make sense,
>> and this is what Apache Commons SCXML already supports and will continue to do.
>> And that requires a lot less headache :)
>>
>> Thanks,
>> Ate
>>
>>>
>>> I'm willing to be persuaded that we're wrong, though.  It may well be that our
>>> intended interpretation causes problems that we did not foresee.
>>>
>>> - Jim
>>> P.S. Everyone who has worked with the XPath data model has had problems with it.
>>>
>>>
>>>
>>> On 2/9/2015 4:20 PM, Ate Douma wrote:
>>>> 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
>>>>>
>>>>
>>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Zjnue Brzavi
In reply to this post by Ate Douma
Hi Ate,
 
What I'm wondering about is why there is this required to define a <data> element in the first place. I assume there is (was) a good and explicit reason
for it.
The only argument I could come up with was that it is used/needed for
data communication, ensuring a predefined 'container' <data> node.
But if that argument is correct, *then* it doesn't make sense to NOT require
this throughout all xpath data model accessors, including the variables, as
otherwise this whole 'assurance' would break, depending on which xpath variable
could/might have been 'broken' this 'contract' because of some intermediate <foreach> usage somewhere. Especially for xpath variables which *initially* were
initialized/binded to a 'top level' <data> element.

Anyway, this of course all is speculation and interpretation my side.
As you said: the xpath data model definitely is causing a lot of problems.

And just FYI (and I already informed Jim about this), I've decided earlier
today to cancel my attempt to implement and complete the xpath data model for
Apache Commons SCXML.
Not all of a sudden or because of the current topic we're discussing, but
because it just turns out too much trouble getting it right, for very little
actual gain/usage. That is: in the case of Apache Commmons SCXML.

After a better review of the initial case you've mentioned here I understand that:
Consistent setting of Var2 would result in:  Var2 => <data id="Var2"><node>1</node></data>
However, my workaround resulted in:         Var2 => <node>1</node>

So I understand your proposal and why the extra access specifier is required in order to reach the text node value.
I would also argue that consistent setting of Var2 (which is an upper-level variable) would seem correct.

In any event, a pity to hear your XPath datamodel venture is coming to an end.

Do you happen to have a list of other problem areas with the XPath datamodel and tests, that could guide others who might want to pick up the task?

Kind regards,
Zjnue