Re: State of the XPath datamodel tests

On Apr 22, 2013, at 6:05 PM, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

>  Do you mean specifically the tests for the XPath datamodel, or the larger set of tests when run on the XPath datamodel?  In the former case, Johan's Spyderbrain system passes all the tests except 483 and 568.  It passes almost all the tests in the latter case as well, but I don't remember which ones fail.  

I was talking about the txmls transformed for the XPath datamodel.

> This doesn't mean that there aren't problems in the tests, of course, but they should be in good enough shape to be worth debugging.  

Ok then, let's first get some general things out of the way before we dive in. I am using SaxonHE9-4-0-7J to perform the xslt transformations.

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.

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? But later in test147, there is a
  <transition event="bar" cond="$Var1/text() =1" target="pass"/>

Which assumes that Var1 is an element with text content as far as I understand xpath. Maybe I stared too long at the whole thing and missed something obvious or it is in fact the erroneous xslt transformations, but I can't get one set of tests to pass without tearing down another set.

Another thing that is at least confusing (with regard to the "XML in content debate inline or via src" we had earlier) is in test153.xml:
  <data id="Var3">
    <node xmlns="">1</node><node xmlns="">2</node><node xmlns="">3</node>
  </data>

Such a construct is not expressible by using the data.src attribute as the XML contained in data can itself not be expressed as a document (multiple roots). David argued that they ought to be interchangeable and we somewhat agreed.

If we get these things clarified, I can work on a more detailed list of inconsistencies.

Best regards
Stefan

> - 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 Tuesday, 23 April 2013 22:16:42 UTC