Re: State of the XPath datamodel tests

Stefan,

As Jim noted, I've implemented the xpath datamodel in pyscxml for the purpose of getting this standard out of the door, hopefully i can clarify a few things. 

> For starters, there is one issue still with the ecma xslt in test153.scxml, the condition gets generated with a superfluous /text() expression:
>  <if cond="Var1/text() &lt;Var2/text() ">
> 
> It's pretty clear that this is non-sense in the ecma datamodel, but it makes you wonder whether there are similar issues with the xpath xslt that would result in unimplementable tests not easily identified. Maybe you could provide the tests after the xslt transformations in an archive as well? Just to be sure we are not debugging xslt but scxml.

I'm afraid there may still be errors in the transformations, we should all try to keep our eyes open and hopefully we'll squash the remaining bugs. 

> 
> With regard to the xpath datamodel in general I am still not sure what to bind the xpath variables to. The draft specifies: "For each <data> element in the document, the SCXML Processor must create a child of <datamodel> called <data> with an 'id' attribute whose value is the same as that of the 'id' attribute of the document <data> element. The Processor must insert the value of the document <data> element as the child(ren) of the datamodel <data> element." That's pretty straight forward. the next part says "The Processor must also bind an XPath variable of the same name to that datamodel <data> element."
> 
> I read it that every bound xpath variable references a XML <data> element, at least initially. This conflicts with test147 though:
> <datamodel>
>  <data id="Var1" expr="0"/>
> </datamodel>
> 
> This results in <data id="Var1">0</data> bound to Var1, which is in conflict with the assignment <assign location="$Var1" expr="$Var1 + 1"/> where $Var1 is supposed to have a numberValue and not to be an element. I guess I am supposed to actually bind the XPath variable to the child(ren) of the data element?

no, the xpath variable has to be bound to the data element itself. the assignment behavior you noted above  is meant to mirror the flexible nature of xpath datatypes, like in this example:

<root><data>1</data></root>

./data = 1 (evaluates to true)
./data/text() = 1 (evaluates to true)

<root><data>1<inner>2</inner></data></root>
./data = 1 (evaluates to false)
./data/text() = 1 (evaluates to true)

we think that the xpath datamodel should be consistent in this behavior, so that expr="$Var1 + 1" will evaluate the lone text content of $Var1 if $Var1 points to an element or the nodeValue (in DOM parlance) of $Var1 if $Var1 points to a text node. 


> But later in test147, there is a
>  <transition event="bar" cond="$Var1/text() =1" target="pass"/>

perhaps it's confusing that many of the tests use /text() when this is not actually needed (as per my example above). we should get rid of this extra cruft, but the semantics of the tests won't change as a result. 

regards,
johan

> 
> 
>> - Jim
>> 
>> -----Original Message-----
>> From: Stefan Radomski [mailto:radomski@tk.informatik.tu-darmstadt.de] 
>> Sent: Monday, April 22, 2013 11:31 AM
>> To: www-voice@w3.org (www-voice@w3.org)
>> Subject: State of the XPath datamodel tests
>> 
>> Hey there,
>> 
>> I tried the last two days to get the xpath datamodel tests to pass and failed rather miserably. Are they in a state that can be implemented? That is, does any implementation pass them all or at least a significant subset? I am hesitant to write a detailed lists of inconsistencies in the tests only to realize that they are not considered to be implementable yet.
>> 
>> Best regards
>> Stefan
>> 
> 
>

Received on Wednesday, 24 April 2013 08:23:26 UTC