- From: Ate Douma <ate@douma.nu>
- Date: Mon, 10 Nov 2014 15:47:20 +0100
- To: www-voice@w3.org
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 14:47:53 UTC