[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 197: Un-initializing BPEL variables
Alex Yiu wrote: > > Hi Assaf, > > You raised a good point. > As you said, if a text node does not have a parent, it is OK to have a > zero length value. However, I still have some reservation. > > Consider these 3 cases of from-spec (after 103 syntax changes): > > 1. <from><literal /></from> (empty literal value?) > 2. <from /> (empty expression) > 3. <from> '' </from> (expression of an empty string) > I'm in favor of 1 (or 2 for that matter), not in favor of 3. #1 would construct an XML tree from the contents of the literal element. The tree could potentially be empty (see below), since empty is just another form of content (i.e. no special case or processing required). Depending on what you ask the XPath engine to return as result type, you'll get an empty node-set, empty string, 0.0, false, etc. #2 could be a shortcut for #1, or un-initialize the variable (does that even make sense?) #3 could work, but if you can also do it using #1, which supports all forms of content, then you know have to equivalent mechanisms. I prefer to keep things simple, so I'll want to always generate any form of content using #1, and so prefer to only read #1. > > Definitely, we need to support (3). > I would say we should disallow (2) explicitly. > > As of this moment, I still have a preference of disallowing (1), > because I prefer simplicity in our spec: > > * I guess it now depends on how we interpret whether the text node > has a parent or not. > Yes, we can construct an empty text node at runtime which does > not have a parent. However, <literal> element does not have an > empty text node from the perspective of source code XML infoset > at compile time. If we want to support (3), we need to make a > special case in the spec to handle that. That is: > I feel inclined to get into some implementation details in order to show how simple this can be, so here's a simple algorithm that will get the job done:: When loading the process definition find the 'literal' node. Create a new DocumentFragment (DOM Level 1, or you favorite API) Traverse all the children of the 'literal' node and copy them as children of the DocumentFragment. When executing the expression, use that DocumentFragment as the context node. It's simple and it supports any content that you can express as child nodes of the literal element: empty literal element, character data, XML elements of arbitrary complexity, sequence of XML elements, mixed content, etc. Assaf > * > > > If the <literal> does not have a child at compile time, we would > create an empty text node at runtime for the from-spec value, > otherwise we will reuse the children XML infoset as the runtime. > > * As I said mentioned, the value returned from <literal /> can be > interpreted as an empty nodeset. (think of applying XPath "./*" > to the <literal /> element). > > * Also, we can use (3) to copy an empty string value to the data > pointed by to-spec already. Why do want to want to create > another way to do similar things? > > Hence, I prefer disallowing this construct which is potentially > ambiguous to users, while we have (3) to do similar things. > > Anyway, one way or the other is not the end of the world. :-) > Thanks for pointing out this parent issue! :-) > > > > Regards, > Alex Yiu > > > > > Assaf Arkin wrote: > >> 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? >> >> >> If you use the content of the literal to create a text node, and you >> pass that text node to the XPath engine as the context node, then the >> text node can be empty. Since it has no parent, you are not violating >> the rule of 6.7 (which is so phrased to allow you to do that, while >> also supporting text node normalization). >> >> If you use the content of the literal to create a document node, you >> must first normalize the document node before passing it to the XPath >> engine as the context node. (If the XPath engine accepts >> non-normalized nodes as a convenience, it will still process them as >> if they were normalized). When you normalize, consecutive text nodes >> are joined into new text nodes, empty text nodes are discarded. So >> you are processing an empty document node. >> >> Since you are assigning to a simple type, you have two options to >> process the result: >> 1. Ask the XPath engine to return a string value, assign that string >> value to the text node. >> 2. Ask the XPath engine to return a node-set, follow another set of >> rules (below) before you can assign that as a simple type. >> >> If you choose #1, then you already support empty strings, whether you >> use a text node or a document node (and whichever version of XPath >> 1.0 you use). The XPath version will return the string value of the >> node-set, which having one node will be calculated as follows (2.5.2 >> in the XPath 2.0 spec): >> >> "1. For text and document nodes, the typed value of the node is the >> same as its string value, as an instance of the type >> |xdt:untypedAtomic|. The string value of a document node is formed by >> concatenating the string values of all its descendant text nodes, in >> document order >> <http://www.w3.org/TR/2005/WD-xpath20-20050211/#dt-document-order>." >> >> If the text node has empty content, or if the document node has empty >> content, you will receive an empty string. >> >> If you choose #2, you can decide how you want to process the results. >> If you decide to remain consistent with XPath, then you need a few >> more steps to duplicate the heavy lifting that XPath does, but you >> end up with the same results which can support empty literal values. >> (I can go into details if absolutely necessary) >> >> Assaf >> >>> 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 >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >>--------------------------------------------------------------------- >>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]