- From: Ate Douma <ate@douma.nu>
- Date: Tue, 10 Feb 2015 01:12:30 +0100
- To: "www-voice@w3.org" <www-voice@w3.org>
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 >>>>> >>>> >>>> >>> >> >
Received on Tuesday, 10 February 2015 00:12:59 UTC