[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
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]