You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Jaroslav Pullmann <ja...@fit.fraunhofer.de> on 2009/03/23 14:16:35 UTC
[SCXML] Test for node existence with Data()
Hello,
while trying to test for the mere existence of a datamodel node it turned
out, that Data() yields to different results depending on the availability
of an immediate textual content of the node:
1) Example, path does not match, Data() is expected to return null:
<log label="NULL" expr="Data(data,'objectList/object[@status = 1]') == null" />
WARNING: Data(): No nodes matching the XPath expression "objectList/object[@status = 1]", returning null
INFO: NULL: false
-> expected: true
2) Example, same as 1) but tested with empty(), apparently an empty string is returned:
<log label="NULL" expr="empty(Data(data,'objectList/object[@status = 1]'))" />
WARNING: Data(): No nodes matching the XPath expression "objectList/object[@status = 1]", returning null
INFO: NULL: true
3) Example, testing a container with no immediate textual content:
<log label="EMPTY" expr="empty(Data(data,'objectList/object'))" />
WARNING: Data(): Multiple nodes matching XPath expression "objectList/object", returning first
INFO: EMPTY: true
4) Example, testing a leaf element with immediate textual content:
<log label="EMPTY" expr="empty(Data(data,'objectList/object/status'))" />
WARNING: Data(): Multiple nodes matching XPath expression "objectList/object/status", returning first
INFO: EMPTY: false
The method apparently invoked in this context: Object org.apache.commons.scxml.Builtin#data()
calls SCXMLHelper#getNodeValue() to retrieve a textual representation of the node. This is done
at the level of immediate child nodes, which themselves are not processed recursively. According
to 1) and 3) there seems to be no test to distiguish whether a node is missing at all or it has
element only content. For the former I'd expect null as return value, for the latter all text nodes
concatenated in a deep frist traversal of all child nodes ?
Thank you
Jaro
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Test for node existence with Data()
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Mar 24, 2009 at 5:21 AM, Jaroslav Pullmann
<ja...@fit.fraunhofer.de> wrote:
>
> Dear Rahul,
> the availability of the XPathEvaluator you pointed me to [1]
> provided also a solution for this use case.
<snip/>
OK, good to know. Also note that for other languages it is always
possible to use user-defined functions to do what you need in
expressions (if the built-in Data() function isn't fulfilling your
requirements).
A little more on such functions at the bottom of this page:
http://commons.apache.org/scxml/guide/contexts-evaluators.html
-Rahul
> Many thanks!
> Jaro
>
>
>
> [1] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/
>
>
>
>
>
>
> Rahul Akolkar wrote:
>>
>> On Mon, Mar 23, 2009 at 9:16 AM, Jaroslav Pullmann
>> <ja...@fit.fraunhofer.de> wrote:
>>>
>>> Hello,
>>>
>>> while trying to test for the mere existence of a datamodel node it
>>> turned
>>> out, that Data() yields to different results depending on the
>>> availability
>>> of an immediate textual content of the node:
>>>
>>>
>>> 1) Example, path does not match, Data() is expected to return null:
>>>
>>> <log label="NULL" expr="Data(data,'objectList/object[@status = 1]') ==
>>> null" />
>>>
>>> WARNING: Data(): No nodes matching the XPath expression
>>> "objectList/object[@status = 1]", returning null
>>> INFO: NULL: false
>>> -> expected: true
>>>
>> <snip/>
>>
>> IIRC, the reason for not returning null here is that the underlying EL
>> will throw its own exception if further operations (such as the
>> comparison above) are attempted on the null value. The type coercion
>> rules used are aimed at allowing simple arithmetic operations (double,
>> else long, else string) on leaf data nodes.
>>
>>
>>> 2) Example, same as 1) but tested with empty(), apparently an empty
>>> string
>>> is returned:
>>>
>>> <log label="NULL" expr="empty(Data(data,'objectList/object[@status =
>>> 1]'))"
>>> />
>>>
>>> WARNING: Data(): No nodes matching the XPath expression
>>> "objectList/object[@status = 1]", returning null
>>> INFO: NULL: true
>>>
>> <snap/>
>>
>> Yup.
>>
>>
>>> 3) Example, testing a container with no immediate textual content:
>>>
>>> <log label="EMPTY" expr="empty(Data(data,'objectList/object'))" />
>>>
>>> WARNING: Data(): Multiple nodes matching XPath expression
>>> "objectList/object", returning first
>>> INFO: EMPTY: true
>>>
>> <snip/>
>>
>> You are correct in pointing this out, however, as mentioned above the
>> coercion rules were really designed for leaf data nodes (more on this
>> below).
>>
>>
>>> 4) Example, testing a leaf element with immediate textual content:
>>>
>>> <log label="EMPTY" expr="empty(Data(data,'objectList/object/status'))"
>>> />
>>>
>>> WARNING: Data(): Multiple nodes matching XPath expression
>>> "objectList/object/status", returning first
>>> INFO: EMPTY: false
>>>
>> <snap/>
>>
>> Yes, as expected.
>>
>>
>>> The method apparently invoked in this context: Object
>>> org.apache.commons.scxml.Builtin#data()
>>> calls SCXMLHelper#getNodeValue() to retrieve a textual representation of
>>> the node. This is done
>>> at the level of immediate child nodes, which themselves are not
>>> processed
>>> recursively. According
>>> to 1) and 3) there seems to be no test to distiguish whether a node is
>>> missing at all or it has
>>> element only content. For the former I'd expect null as return value,
>>
>> <snip/>
>>
>> At the time the decision was made, the general philosophy to avoid EL
>> blow ups as noted above made sense.
>>
>>
>>> for
>>> the latter all text nodes
>>> concatenated in a deep frist traversal of all child nodes ?
>>
>> <snap/>
>>
>> Possibly. We've generally tried to discourage checking values of
>> anything other than leaf data nodes i.e. given the proposal, the
>> following <foo>s will be coerced to the same value, which is
>> differently strange :-)
>>
>> <foo xmlns="">
>> A
>> <bar>B</bar>
>> </foo>
>>
>> <foo xmlns="">
>> A
>> <otherbar>B</otherbar>
>> </foo>
>>
>> -Rahul
>>
>>
>>
>>> Thank you
>>> Jaro
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Test for node existence with Data()
Posted by Jaroslav Pullmann <ja...@fit.fraunhofer.de>.
Dear Rahul,
the availability of the XPathEvaluator you pointed me to [1]
provided also a solution for this use case.
Many thanks!
Jaro
[1] http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/
Rahul Akolkar wrote:
> On Mon, Mar 23, 2009 at 9:16 AM, Jaroslav Pullmann
> <ja...@fit.fraunhofer.de> wrote:
>>
>> Hello,
>>
>> while trying to test for the mere existence of a datamodel node it turned
>> out, that Data() yields to different results depending on the availability
>> of an immediate textual content of the node:
>>
>>
>> 1) Example, path does not match, Data() is expected to return null:
>>
>> <log label="NULL" expr="Data(data,'objectList/object[@status = 1]') ==
>> null" />
>>
>> WARNING: Data(): No nodes matching the XPath expression
>> "objectList/object[@status = 1]", returning null
>> INFO: NULL: false
>> -> expected: true
>>
> <snip/>
>
> IIRC, the reason for not returning null here is that the underlying EL
> will throw its own exception if further operations (such as the
> comparison above) are attempted on the null value. The type coercion
> rules used are aimed at allowing simple arithmetic operations (double,
> else long, else string) on leaf data nodes.
>
>
>> 2) Example, same as 1) but tested with empty(), apparently an empty string
>> is returned:
>>
>> <log label="NULL" expr="empty(Data(data,'objectList/object[@status = 1]'))"
>> />
>>
>> WARNING: Data(): No nodes matching the XPath expression
>> "objectList/object[@status = 1]", returning null
>> INFO: NULL: true
>>
> <snap/>
>
> Yup.
>
>
>> 3) Example, testing a container with no immediate textual content:
>>
>> <log label="EMPTY" expr="empty(Data(data,'objectList/object'))" />
>>
>> WARNING: Data(): Multiple nodes matching XPath expression
>> "objectList/object", returning first
>> INFO: EMPTY: true
>>
> <snip/>
>
> You are correct in pointing this out, however, as mentioned above the
> coercion rules were really designed for leaf data nodes (more on this
> below).
>
>
>> 4) Example, testing a leaf element with immediate textual content:
>>
>> <log label="EMPTY" expr="empty(Data(data,'objectList/object/status'))" />
>>
>> WARNING: Data(): Multiple nodes matching XPath expression
>> "objectList/object/status", returning first
>> INFO: EMPTY: false
>>
> <snap/>
>
> Yes, as expected.
>
>
>> The method apparently invoked in this context: Object
>> org.apache.commons.scxml.Builtin#data()
>> calls SCXMLHelper#getNodeValue() to retrieve a textual representation of
>> the node. This is done
>> at the level of immediate child nodes, which themselves are not processed
>> recursively. According
>> to 1) and 3) there seems to be no test to distiguish whether a node is
>> missing at all or it has
>> element only content. For the former I'd expect null as return value,
> <snip/>
>
> At the time the decision was made, the general philosophy to avoid EL
> blow ups as noted above made sense.
>
>
>> for
>> the latter all text nodes
>> concatenated in a deep frist traversal of all child nodes ?
> <snap/>
>
> Possibly. We've generally tried to discourage checking values of
> anything other than leaf data nodes i.e. given the proposal, the
> following <foo>s will be coerced to the same value, which is
> differently strange :-)
>
> <foo xmlns="">
> A
> <bar>B</bar>
> </foo>
>
> <foo xmlns="">
> A
> <otherbar>B</otherbar>
> </foo>
>
> -Rahul
>
>
>
>> Thank you
>> Jaro
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
--
Jaroslav Pullmann
Web Compliance Center - Fraunhofer FIT
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142623 Fax: +49-2241-142065
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [SCXML] Test for node existence with Data()
Posted by Rahul Akolkar <ra...@gmail.com>.
On Mon, Mar 23, 2009 at 9:16 AM, Jaroslav Pullmann
<ja...@fit.fraunhofer.de> wrote:
>
>
> Hello,
>
> while trying to test for the mere existence of a datamodel node it turned
> out, that Data() yields to different results depending on the availability
> of an immediate textual content of the node:
>
>
> 1) Example, path does not match, Data() is expected to return null:
>
> <log label="NULL" expr="Data(data,'objectList/object[@status = 1]') ==
> null" />
>
> WARNING: Data(): No nodes matching the XPath expression
> "objectList/object[@status = 1]", returning null
> INFO: NULL: false
> -> expected: true
>
<snip/>
IIRC, the reason for not returning null here is that the underlying EL
will throw its own exception if further operations (such as the
comparison above) are attempted on the null value. The type coercion
rules used are aimed at allowing simple arithmetic operations (double,
else long, else string) on leaf data nodes.
> 2) Example, same as 1) but tested with empty(), apparently an empty string
> is returned:
>
> <log label="NULL" expr="empty(Data(data,'objectList/object[@status = 1]'))"
> />
>
> WARNING: Data(): No nodes matching the XPath expression
> "objectList/object[@status = 1]", returning null
> INFO: NULL: true
>
<snap/>
Yup.
>
> 3) Example, testing a container with no immediate textual content:
>
> <log label="EMPTY" expr="empty(Data(data,'objectList/object'))" />
>
> WARNING: Data(): Multiple nodes matching XPath expression
> "objectList/object", returning first
> INFO: EMPTY: true
>
<snip/>
You are correct in pointing this out, however, as mentioned above the
coercion rules were really designed for leaf data nodes (more on this
below).
> 4) Example, testing a leaf element with immediate textual content:
>
> <log label="EMPTY" expr="empty(Data(data,'objectList/object/status'))" />
>
> WARNING: Data(): Multiple nodes matching XPath expression
> "objectList/object/status", returning first
> INFO: EMPTY: false
>
<snap/>
Yes, as expected.
>
> The method apparently invoked in this context: Object
> org.apache.commons.scxml.Builtin#data()
> calls SCXMLHelper#getNodeValue() to retrieve a textual representation of
> the node. This is done
> at the level of immediate child nodes, which themselves are not processed
> recursively. According
> to 1) and 3) there seems to be no test to distiguish whether a node is
> missing at all or it has
> element only content. For the former I'd expect null as return value,
<snip/>
At the time the decision was made, the general philosophy to avoid EL
blow ups as noted above made sense.
> for
> the latter all text nodes
> concatenated in a deep frist traversal of all child nodes ?
<snap/>
Possibly. We've generally tried to discourage checking values of
anything other than leaf data nodes i.e. given the proposal, the
following <foo>s will be coerced to the same value, which is
differently strange :-)
<foo xmlns="">
A
<bar>B</bar>
</foo>
<foo xmlns="">
A
<otherbar>B</otherbar>
</foo>
-Rahul
>
> Thank you
> Jaro
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org