- From: Ate Douma <ate@douma.nu>
- Date: Tue, 10 Feb 2015 01:02:10 +0100
- To: "www-voice@w3.org" <www-voice@w3.org>
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