[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
Yaron Y. Goland wrote: > Is there a presumption that anything in a literal is a text node? > > E.g. is: > > <literal> > <foo> > <bar/> > </foo> > </literal> > > A text node? Or is it a XML document? I made the assumption that he content of the literal element is an XML tree, not a textual representation of that tree, and used that to validate my proposal. So in this case my answer is, 'foo' is not a text node. Assaf > > Yaron > > Alex Yiu wrote: > >> Hi, Yaron and Assaf, >> >> Regarding to the following syntax, I have some second thought ... [ >> sorry about that :-) ] >> ------------------------------------ >> <assign> >> <copy> >> <from> >> <literal /> >> </from> >> <to variable="x" /> >> </copy> >> </assign> >> ------------------------------------ >> >> I have doubled checked XPath 2.0 data model (section 6.7). It >> explicitly disallows a text node with zero length. >> >> Therefore, the more suitable interpretation of the value returned by >> <literal> should be an empty nodeset. Of course assigning an empty >> nodset to /some /kinds of BPEL variables could make sense in /some >> /condition. However, to avoid catch all the corner cases and to >> maintain consistent semantics of "selectionFailure" fault, I think we >> should outlaw the above usage for XPath 1.0 for now. When we >> officially move to XPath 2.0 data model, we can consider enable the >> above usage. >> >> Thought? >> Thanks! >> >> >> Regards, >> Alex Yiu >> >> >> >> >> >> Alex Yiu wrote: >> >>> >>> Hi, Yaron, >>> >>> You have raised a good question. >>> >>> Using 111.1 syntax: >>> <assign> >>> <copy> >>> <from> >>> <literal /> >>> </from> >>> <to variable="x" /> >>> </copy> >>> </assign> >>> >>> Remember <literal /> = = = <literal></literal> >>> >>> Here is my attempt to answer your question: >>> >>> IMHO, the "empty" literal should yield a empty text-node (similar to >>> empty str). >>> (Of course, the other option is to outlaw it.) >>> >>> If x is of a simple type which can accepts an empty string, the >>> above assignment should be legal. >>> >>> If x is of element or complex type of which has *simple-content* >>> which is derived , there may be cases where this assignment is >>> legal. It depends on Issue 157 - "Cleaning up copy". >>> See an example below: (note this part of decision belongs to 157 , >>> not 197) >>> >>> >>> Before the assignment: x = = <foo:bar>*abc*</foo:bar> >>> After the assignment: x = = <foo:bar></foo:bar> ( = = = <foo:bar />) >>> >>> >>> >>> >>> Thanks! >>> >>> >>> Regards, >>> Alex Yiu >>> >>> >> >> >> Assaf Arkin wrote: >> >>> I believe this should be handled the same way as if we had >>> <staticValue>something</staticValue>. I mean, either it can assign a >>> text node (empty or not) to the element variable, or it throws a >>> fault. Otherwise, we have an exception for the case where the >>> assigned value is character data, but happens to have a particular >>> length. >>> >>> Assaf >>> >>> Yaron Y. Goland wrote: >>> >>>> I'm fine having a special attribute and think it would be a fine >>>> part of resolving this issue. But it still leaves open a question, >>>> what is the consequence of: >>>> >>>> <assign> >>>> <copy> >>>> <from> >>>> <!-- Or whatever we agreed to call it in 111.1 --> >>>> <staticValue/> >>>> </from> >>>> <to variable="x" /> >>>> </copy> >>>> </assign> >>>> >>>> >>>> Let's assume that variable X is of type element, specifically <Foo/>. >>>> >>>> What happens to X? Is it uninitialized? It can't be 'empty' because >>>> X MUST contain an element named <Foo>, that is required by its >>>> nature as an element variable. So what's left? We can either >>>> declare the above to always be illegal or we can declare that it >>>> uninitializes the variable or we can even try some interesting >>>> conversation routines (e.g. treat the source as a text node >>>> intended to be made the child of Foo) but we need to say something. >>>> >>>> Yaron >>>> >>>> Alex Yiu wrote: >>>> >>>>> Hi, >>>>> >>>>> With limited thinking cycle spent in this topic, I would prefer >>>>> have a special-form of from-spec to solve this problem: >>>>> <assign> >>>>> <copy> >>>>> <from */a_new_attr_name/="yes"* /> >>>>> <!-- let's say, the attribute name is: "*uninitialized*" --> >>>>> <to variable="x" /> >>>>> </copy> >>>>> </assign> >>>>> >>>>> This uninitialized attribute just controls the special flag >>>>> associated with a variable value to indicate whether a variable >>>>> value has been assigned to that variable. Hence, we don't need to >>>>> come up with special values which are valid to the associated >>>>> varaible types to indicate the "uninitialized" status of the >>>>> variable. >>>>> >>>>> For sake of argument, let's assume one implementation has the >>>>> following extensions: >>>>> >>>>> * <foo:xcopy> which allows the from-spec yield zero nodes >>>>> * A variable type that can store the nodeset of XPath 1.0 or the item >>>>> sequence of XQuery 1.0. (That is, $varY) >>>>> >>>>> >>>>> For >>>>> <assign> >>>>> <extensibleAssign> >>>>> <!-- sigh ... the verbose amendment here ... :-) ... --> >>>>> <foo:xcopy> >>>>> <from> $varX/po:lineItem[10] </from> >>>>> <to> $varY </to> >>>>> </foo:xcopy> >>>>> </extensibleAssign> >>>>> </assign> >>>>> >>>>> It is a useful value for a variable to points to an empty result >>>>> result. >>>>> So, we can do the following expression: "count($varY) > 0" >>>>> That is: we need to differentiate between an "empty-result-set" >>>>> situation and "we-don't-have-a- result-set" situation. >>>>> >>>>> Similar semantics consideration would be applied to simple-type >>>>> variables and WSDL message variable (the >>>>> source-of-all-data-related-complication). [ Asking me to come up >>>>> with a sensible XML Infoset to represent an uninitialized WSDL >>>>> message would make my head hurt. :-) ] >>>>> >>>>> In short, IMHO, a special form of from-spec is the >>>>> /_simplest-and-cleanest_/ solution to this problem. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Alex Yiu >>>>> >>>>> >>>>> >>>>> Assaf Arkin wrote: >>>>> >>>>>> Yaron Y. Goland wrote: >>>>>> >>>>>>> Your argument works for text nodes but not elements and who says >>>>>>> that the contents of a static value that contains nothing is a >>>>>>> text node? That certainly isn't defined in the spec today. In >>>>>>> fact we have at least 2 open issues on exactly this kind of >>>>>>> problem. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I made no such assumption. To assign a value to a text node I >>>>>> need to obtain a string value, but if you read the XPath >>>>>> expression, I can operate on a variety of content models in order >>>>>> to arrive at that string value. >>>>>> >>>>>> Since I consider an empty value to be a valid and useful value, >>>>>> we need a way to disambiguate between un-initializing a variable >>>>>> and expressions that can assign an empty value to a text node. >>>>>> Since we want to keep it simple, let's find an un-initializing >>>>>> mechanism that is not node-type specific, and retain that >>>>>> distinction across all node types. >>>>>> >>>>>> Assaf >>>>>> >>>>>>> >>>>>>> Assaf Arkin wrote: >>>>>>> >>>>>>>> In XML empty is still a content. An empty text node contains >>>>>>>> zero characters. Different from nothing or null. >>>>>>>> >>>>>>>> For example, if I have the expression concat($X,$Y) it is valid >>>>>>>> for Y to be empty, and its reasonable for someone to set it to >>>>>>>> empty and be used. $Y needs to have a value in this case and >>>>>>>> the expression need to evaluate. >>>>>>>> >>>>>>>> Un-initialize will require its own construct, a) to not confuse >>>>>>>> between empty and null, and b) since we currently do not allow >>>>>>>> null to be selected. >>>>>>>> >>>>>>>> Assaf >>>>>>>> >>>>>>>> Tony Fletcher wrote: >>>>>>>> >>>>>>>>> This issue has been added to the wsbpel issue list with a >>>>>>>>> status of "received". The status will be changed to "open" if >>>>>>>>> the TC accepts it as identifying a bug in the spec or decides >>>>>>>>> it should be accepted specially. Otherwise it will be closed >>>>>>>>> without further consideration (but will be marked as >>>>>>>>> "Revisitable") >>>>>>>>> >>>>>>>>> The issues list is posted as a Technical Committee document to >>>>>>>>> the OASIS WSBPEL TC pages >>>>>>>>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a >>>>>>>>> regular basis. The current edition, as a TC document, is the >>>>>>>>> most recent version of the document entitled in the "Issues" >>>>>>>>> folder of the WSBPEL TC document list >>>>>>>>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> >>>>>>>>> - the next posting as a TC document will include this issue. >>>>>>>>> The list editor's working copy, which will normally include an >>>>>>>>> issue when it is announced, is available at this constant URL >>>>>>>>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Issue 197: Un-initializing BPEL variables >>>>>>>>> >>>>>>>>> *Status:* received >>>>>>>>> *Date added:* 12 Mar 2005 >>>>>>>>> *Categories:* Data Handling >>>>>>>>> <http://www.choreology.com/external/WS_BPEL_issues_list.html#category_data_handling> >>>>>>>>> >>>>>>>>> *Date submitted:* 11 March 2004 >>>>>>>>> *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> >>>>>>>>> *Description:* Is it legal/possible to un-initialize a >>>>>>>>> variable in BPEL? What happens, for example, if one tries to >>>>>>>>> assign a static from value that is empty? Should we allow for >>>>>>>>> from-spec to be empty and have that mean that the target is >>>>>>>>> uninitialized? >>>>>>>>> *Submitter’s proposal:* Being able to un-initialize variables >>>>>>>>> is a generically useful thing. It makes it clear when a >>>>>>>>> variable doesn't contain a 'useful' value. So I think we >>>>>>>>> should provide a way to un-initialize variables. >>>>>>>>> *Changes:* 12 Mar 2005 - new issue >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Tony/ / >>>>>>>>> >>>>>>>>> / <http://www.choreology.com/>/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Tony Fletcher >>>>>>>>> >>>>>>>>> Technical Advisor >>>>>>>>> Choreology Ltd. >>>>>>>>> 68, Lombard Street, London EC3V 9L J UK >>>>>>>>> >>>>>>>>> Phone: >>>>>>>>> >>>>>>>>> >>>>>>>>> +44 (0) 1473 729537 >>>>>>>>> >>>>>>>>> Mobile: >>>>>>>>> >>>>>>>>> >>>>>>>>> +44 (0) 7801 948219// >>>>>>>>> >>>>>>>>> Fax: >>>>>>>>> >>>>>>>>> >>>>>>>>> +44 (0) 870 7390077 >>>>>>>>> >>>>>>>>> Web: >>>>>>>>> >>>>>>>>> >>>>>>>>> /www.choreology.com <http://www.choreology.com/>/ >>>>>>>>> >>>>>>>>> Cohesions™ >>>>>>>>> >>>>>>>>> Business transaction management software for application >>>>>>>>> coordination >>>>>>>>> >>>>>>>>> Work: tony.fletcher@choreology.com >>>>>>>>> >>>>>>>>> Home: amfletcher@iee.org <mailto:amfletcher@iee.org> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org >>>>>> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org >>>>>> >>>>> >>>> >>>> >>> >> > >
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]