Re: [SCXML] Incorrect XPath expressions in IR tests 153 & 155
Jim Barnett <[email protected]> Mon, 09 Feb 2015 17:17:30 -0500
| Newsgroups | gmane.comp.web.voice |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------070806010505050302060002
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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
>>
>
>
--------------070806010505050302060002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ate,<br>
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 "<a id="N108BE" name="N108BE">The
SCXML processor <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> 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. <br>
<br>
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.) <br>
<br>
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. <br>
<br>
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. <br>
<br>
- Jim<br>
P.S. Everyone who has worked with the XPath data model has had
problems with it. <br>
<br>
<br>
<br>
</a>
<div class="moz-cite-prefix">On 2/9/2015 4:20 PM, Ate Douma wrote:<br>
</div>
<blockquote cite="mid:[email protected]" type="cite">Hi
Zjnue,
<br>
<br>
<br>
On 2015-02-09 19:28, Zjnue Brzavi wrote:
<br>
<blockquote type="cite">Hi Ate,
<br>
<br>
<datamodel>
<br>
<data id="Var1" expr="0"/>
<br>
<data id="Var2"/>
<br>
<data id="Var3">
<br>
<node xmlns="">1</node><node
xmlns="">2</node><node xmlns="">3</node>
<br>
</data>
<br>
<data id="Var4" expr="1"/>
<br>
</datamodel>
<br>
<br>
[..]
<br>
<br>
The "Var2/text()" xpath expressions in the if condition
check and the
<br>
assignment value expression above are not valid/usable in
this context.
<br>
<br>
The foreach element will assign each of the Var3
<node>x</node> children to
<br>
the Var2 variable, and the Var2 variable (its data node)
thus will contains
<br>
no (direct) text node children, only a (single) "node"
child.
<br>
<br>
To access the actual text value of that "node" child, the
expression must
<br>
be: "$Var2/*/text()" or if desired "$Var2/node[1]/text()".
<br>
<br>
<br>
This is something I've implemented also, and on this rare
occasion I have to
<br>
disagree with the suggestion.
<br>
<br>
Let's take this SO post as context:
<br>
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/11744465/xpath-difference-between-node-and-text">http://stackoverflow.com/questions/11744465/xpath-difference-between-node-and-text</a>
<br>
<br>
Now back to the example you've stated.
<br>
Var3 evaluates to an XMLList, which has this simplified
structure:
<br>
<br>
element node (name="node")
<br>
text node (value="1")
<br>
element node (name="node")
<br>
text node (value="2")
<br>
element node (name="node")
<br>
text node (value="3")
<br>
<br>
Now, in the foreach structure, as we iterate through this list,
we assign a
<br>
reference to the next element node to Var2.
<br>
In turn, $Var2/text() evaluates to 1, 2 and 3 as we expect.
<br>
<br>
My guess is that your implementation creates a new XML instance
when assigning
<br>
values to Var2, giving it values such as:
<br>
<br>
root node
<br>
element node (name="node")
<br>
text node (value="1")
<br>
<br>
root node
<br>
element node (name="node")
<br>
text node (value="2")
<br>
<br>
and so on, thereby requiring the extra axis specifier as you
suggested:
<br>
$Var2/*/text() OR $Var2/node[1]/text()
<br>
<br>
However, as we are dealing with a complex type, I believe it is
wrong to create
<br>
new instances and that we should use references to the existing
nodes, making
<br>
the tests valid as they are currently specified.
<br>
<br>
In my implementation, I have a normalized foreach routine for
the different
<br>
datamodels:
<br>
<a class="moz-txt-link-freetext" href="https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Interp.hx#L935-L972">https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Interp.hx#L935-L972</a>
<br>
<br>
This works well for the tests mentioned, when I feed it with an
array containing
<br>
references to the different nodes in the XMLList, formed here:
<br>
<a class="moz-txt-link-freetext" href="https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Model.hx#L354-L366">https://github.com/zjnue/hscxml/blob/master/src/hsm/scxml/Model.hx#L354-L366</a>
<br>
<br>
Do you agree?
<br>
</blockquote>
<br>
I agree such a solution was what I also implemented initially.
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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()".
<br>
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.
<br>
<br>
But, maybe I've been assuming and interpreting too much into
this...
<br>
Trying to get the xpath datamodel implementation working properly,
and as intended, has been (and still is) quite a challenge so say
the least.
<br>
<br>
Maybe Jim can chime in and help clarify what the actual or
intended requirements concerning XPath variables are.
<br>
<br>
Thanks, Ate
<br>
<br>
<blockquote type="cite">
<br>
Best regards,
<br>
Zjnue
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------070806010505050302060002--