Re: [SCXML] Incorrect XPath expressions in IR tests 153 & 155

--047d7bdc87a24036a7050edf9898
Content-Type: text/plain; charset=ISO-8859-1

Hi Ate,


> 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.
>
> 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.
>

After a better review of the initial case you've mentioned here I
understand that:
Consistent setting of Var2 would result in:  Var2 => <data
id="Var2"><node>1</node></data>
However, my workaround resulted in:         Var2 => <node>1</node>

So I understand your proposal and why the extra access specifier is
required in order to reach the text node value.
I would also argue that consistent setting of Var2 (which is an upper-level
variable) would seem correct.

In any event, a pity to hear your XPath datamodel venture is coming to an
end.

Do you happen to have a list of other problem areas with the XPath
datamodel and tests, that could guide others who might want to pick up the
task?

Kind regards,
Zjnue

--047d7bdc87a24036a7050edf9898
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ate,<br><div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><span class=3D""></span>
What I&#39;m wondering about is why there is this required to define a &lt;=
data&gt; element in the first place. I assume there is (was) a good and exp=
licit reason<br>
for it.<br>
The only argument I could come up with was that it is used/needed for<br>
data communication, ensuring a predefined &#39;container&#39; &lt;data&gt; =
node.<br>
But if that argument is correct, *then* it doesn&#39;t make sense to NOT re=
quire<br>
this throughout all xpath data model accessors, including the variables, as=
<br>
otherwise this whole &#39;assurance&#39; would break, depending on which xp=
ath variable<br>
could/might have been &#39;broken&#39; this &#39;contract&#39; because of s=
ome intermediate &lt;foreach&gt; usage somewhere. Especially for xpath vari=
ables which *initially* were<br>
initialized/binded to a &#39;top level&#39; &lt;data&gt; element.<br>
<br>
Anyway, this of course all is speculation and interpretation my side.<br>
As you said: the xpath data model definitely is causing a lot of problems.<=
br>
<br>
And just FYI (and I already informed Jim about this), I&#39;ve decided earl=
ier<br>
today to cancel my attempt to implement and complete the xpath data model f=
or<br>
Apache Commons SCXML.<br>
Not all of a sudden or because of the current topic we&#39;re discussing, b=
ut<br>
because it just turns out too much trouble getting it right, for very littl=
e<br>
actual gain/usage. That is: in the case of Apache Commmons SCXML.<br></bloc=
kquote><div><br></div><div>After a better review of the initial case you&#3=
9;ve mentioned here I understand that:<br>Consistent setting of Var2 would =
result in:=A0 Var2 =3D&gt; &lt;data id=3D&quot;Var2&quot;&gt;&lt;node&gt;1&=
lt;/node&gt;&lt;/data&gt;<br>However, my workaround resulted in:=A0=A0=A0=
=A0=A0=A0=A0=A0 Var2 =3D&gt; &lt;node&gt;1&lt;/node&gt;<br><br></div><div>S=
o I understand your proposal and why the extra access specifier is required=
 in order to reach the text node value.<br></div><div>I would also argue th=
at consistent setting of Var2 (which is an upper-level variable) would seem=
 correct.<br><br></div><div>In any event, a pity to hear your XPath datamod=
el venture is coming to an end.<br><br></div><div>Do you happen to have a l=
ist of other problem areas with the XPath datamodel and tests, that could g=
uide others who might want to pick up the task?<br><br></div><div>Kind rega=
rds,<br>Zjnue<br></div><div><br></div></div></div></div></div>

--047d7bdc87a24036a7050edf9898--