Re: [SCXML] IRP test579 and test580 produce invalid xpath syntax

On 2014-11-10 16:06, Jim Barnett wrote:
> Ate,
>    Can you clarify a bit?  If we change the xslt file to map '==' onto '=' in
> Xpath, what is the problem with the ones that have 'conf:idVal="1=1"'.  They
> would also map onto '='.  Or is the problem something other than than '==' vs. '='?

What I wanted to point out is that already other tests (like 147 and many more), 
do use conf:idVal="1=1" (or likewise) in the txml, which get properly 
transformed for both xpath and ecmascript.

If you 'fix' this for tests 579 and 580 only in the xslt, you actually are 
introducing two separate ways of defining such condition, for xpath that is.
Making the xpath xslt more 'lenient' so to say.

While if you change the 579 and 580 txml file, you're using the same and a 
single type of definition already used for many other tests.
To me it seems trivial and just much cleaner to do the latter.

>
> There are two other implementations that support XPath that I'm aware of:
> PySCXML and hscxml.  I ran the XPath tests on PySCXML when I wrote them, but
> that was a couple of years ago, and there have been a number of changes since
> then.  The author of PyScxml is updating his implementation now, but hasn't
> filed an IR report, so I don't know if he's run the XPath tests recently.
> hscxml does support XPath, but its author had already filed an IR for the core
> mandatory tests using another datamodel, so when he added XPath support, he ran
> only the tests that were specific to the XPath datamodel (i.e. those for section
> B.3). uscxml says it has rudimentary support for the XPath datamodel, but its
> authors haven't filed an IR report for XPath, so I don't know how many of the
> tests they have run.
>
> In short, I think that you're the first person to exercise the full
> confXPath.xsl file in a couple of years.

Right.
If I'm hitting more IRP quirks I'll let you know.

Regards,

Ate

>
>   - Jim
>
> - Jim
> On 11/10/2014 9:47 AM, Ate Douma wrote:
>> On 2014-11-10 15:00, Jim Barnett wrote:
>>> Ate,
>>>    You're right that this doesn't work in XPath.  My only question is whether we
>>> should change the txml or the XPAth xslt file.  The XPatth definition of
>>> conf:idVal could insert the single '=' in place of the '=='. This would leave
>>> the ECMA tests untouched  (and I remember some strong opinions about whether to
>>> use '=' or '==' in ECMA.)
>>
>> There are many other tests, like for example test147, having the same type of
>> condition check like 'conf:idVal="1=1"'.
>> So I'd say we either change the txml for 579 and 580 accordingly, or else
>> change all the other txml files.
>> Seems like an easy choice to me :)
>>
>>>
>>> The XPath tests haven't been run in a couple of years.  We've made a number of
>>> changes to the tests since then, so I think it's likely that you will find other
>>> problems as well.
>>
>> OK, thanks for the heads up.
>> I thought there were other implementations (like uscxml?) also supporting xpath?
>>
>> Ate
>>
>>>
>>> - Jim
>>> On 11/9/2014 9:08 PM, Ate Douma wrote:
>>>> Hi,
>>>>
>>>> I just noticed this with the IRP test579 and test580.
>>>>
>>>> Both these tests define transitions with conditions conf:idVal="1==0" or
>>>> conf:idVal="1==1". When transformed with the confXPath.xsl stylesheet this
>>>> leads to invalid xpath syntax cond="$Var1/text() ==0" or cond="$Var1/text()
>>>> ==1"
>>>>
>>>> Seems unlikely to me anyone testing these for the xpath datamodel gets them to
>>>> pass.
>>>>
>>>> NB: these tests do produce correct ecmascript syntax when using the
>>>> confEcma.xsl...
>>>>
>>>> After I manually fixed these conditions in the txml to conf:idVal="1=0" and
>>>> conf:idVal="1=1", both tests work fine and pass in my implementation (for both
>>>> ecmascript and xpath).
>>>>
>>>> So I think these tests should be fixed like this.
>>>>
>>>> Thanks,
>>>>
>>>> Ate
>>>>
>>>
>>>
>>
>>
>
>

Received on Monday, 10 November 2014 15:35:32 UTC