commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [SCXML] Retrieving a (wrapped) NodeSet for an XPath / user defined XPath functions
Date Thu, 22 Oct 2009 22:14:18 GMT
On Thu, Oct 22, 2009 at 3:00 AM, Jaroslav Pullmann
<jaroslav.pullmann@fit.fraunhofer.de> wrote:
>
>
>  Dear Rahul,
>  thank you for responding. Essentially the use case is simply
>  a selection of a NodeSet instead of a Node and this seeems
>  to be what the spec (WD May 2008) guarantees:
>
>  9.3.3.1 Location Expressions:
>  "XPath 2.0 expressions are used to select a node-set
>  from the data model by providing a binding expression..."
>
<snip/>

A location expression should identify a unique location in the
datamodel so IMO that needs to change -- I'll bring it up with the WG.
 Thanks for pointing it out.


>  9.3.3.2 Value Expressions:
>  "If the result of the value expression is a node-set,
>  a deep copy of the subtree rooted at each node is made."
>
<snap/>

Value expressions can return nodesets.


>  Given this I wonder why the signature of the method
>
>    Node   Evaluator#evalLocation(Context ctx, String expr)
>
>  is limited to delivering (the first result) XPathConstants.NODE ?
>
>  This single node seems to provides just a conventient container for
>  copying the child nodes in Assign#execute() and be passed as an Invoker
>  argument. Could this restrictive contract change in future releases ?
>
<snip/>

See comment above WRT location expressions. Whether evalLocation()
will change depends on the outcome with the WG, once I get a chance to
check there.

-Rahul


>    Many thanks
>     Jaro
>
>
>
>
>
> Rahul Akolkar wrote:
>>
>> On Tue, Oct 20, 2009 at 10:42 AM, Jaroslav Pullmann
>> <jaroslav.pullmann@fit.fraunhofer.de> wrote:
>>>
>>>  Dear Rahul, dear all,
>>>
>>>  the result value of an XPath-selection is limited to an
>>> XPathConstants.NODE
>>>  as of XPathEvaluator#evalLocation(Context, String). Having a root
>>> element
>>> is
>>>  reasonable for assignments etc. but I'd need to select a NodeSet based
>>> on
>>> the
>>>  XPath predicates first (and then wrap it evt. into a result element).
>>>
>> <snip/>
>>
>> Right, the XPathEvaluator only supports types that it needs to fulfill
>> its contracts (generic expression, boolean or node result). Executing
>> an operation or task with arbitrary semantics requires either
>> extension functions or custom actions.
>>
>>
>>>  My use case resembles the form interpretation algorithm (FIA) of VXML:
>>> the
>>>  <datamodel> of a state is updated continually by the payload of arriving
>>> events
>>>  (inputs). There is an UI (form) which reflects the current datamodel and
>>> on
>>> each
>>>  change the remaining "empty" <data> items should be selected and
>>> presented
>>> for
>>>  completion:
>>>
>>> <state id="collectInput">
>>>       <datamodel>
>>>               <data id="statedata">...</data>
>>>               <data id="empty"><my:empty xmlns:my="urn:myns"/></data>
>>>       </datamodel>
>>>
>>>
>>>       <transition event="submit">
>>>
>>>               <!-- store input -->
>>>               <assign expr="$_eventdata/data"
>>> location="$statedata/dataitem[@id = $_eventdata/data/@id]"/>
>>>
>>>               <!-- test for remaining empty fields, wrap resulting
>>> NodeSet
>>> into "my:empty" element  -->
>>>               <assign expr="my:filter($statedata/item[. =
>>> ''],'my:empty')"
>>> location="$empty" />
>>>
>>>               <myfn:updateGUI/>
>>>
>>>       </transition>
>>>
>>>       <transition cond="count($empty/my:empty) = 0"
>>> target="nextInputState"
>>> />
>>>
>>>  </state>
>>>
>>>
>>>  Although the XPathEvaluator accpets XPathFunctions as constructor
>>> arguments,
>>>  there are no public accessors to the namespace and variable contexts.
>>> Could
>>> you
>>>  please provide an exmaple how to accomplish access to a data NodeSet
>>> using
>>> an
>>>  XPathFunction or an other way ?
>>>
>> <snap/>
>>
>> You're correct that the namespace and variable contexts are not
>> trivially exposed to the functions and that is also sort of a thumb
>> rule on whether to use a function or an action.
>>
>> I'd recommend using a custom action that captures these specific
>> semantics aiding behavior akin to the FIA, rather than having it
>> happen as a side-effect of a function invocation in an assignment
>> expression. IOW, if you have an action to the effect of the following
>> that has the behavior above:
>>
>>  <myfn:assign nodeset="$statedata/item[. = '']" wrapper="my:empty"
>> location="$empty"/>
>>
>> it (a) offers you access to the namespace and variable contexts, and
>> (b) models this separately from <assign> since it is indeed a
>> composite operation.
>>
>> -Rahul
>>
>>
>>>  Many thanks !
>>>   Jaro
>>>
>>>
>>>
>>> --
>>> 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
>>
>
>
> --
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message