[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
Hi I would also interprete <foo> as an XML Element node, NOT a text node in this case. Regards, Alex Yiu Assaf Arkin wrote: > 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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]