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

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

Received on Tuesday, 10 February 2015 00:02:39 UTC