[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Proposal For Vote
The key here is that the core behavior needs to be described using infoset terminology. The proposal doesn't currently do that and so isn't language independent. That is, someone using a language other than XPATH will fail. There is no need to cause that failure since infoset gives us a standardized mechanism to prevent it. This applies as much to Ugo's proposal as to yours. Yaron Chris Keller wrote: > Hi Yaron, > > Good point would it help if I restated the first paragraph of the proposal > as this: > > Proposal: The most requested form of data manipulation not currently covered > by <copy> is the ability to incrementally create new complex messages in > order to invoke services or reply from a process. This proposal suggests we > add a create attribute to the existing <query> child element of the <to> > element. When this option is set to "yes" and the query's information item > does not exist then the information item represented by the query will be > created. > > ------------------------------------------- > > The rest of the proposal presents samples and restrictions for using XPath > as the query's language. I am not sure I can restate it completely in > Infoset, but could try to restate it, if you feel that would help. > > ------------------------------------------- > > Just a note the copy operation already allows us to create/initialize the > <to> message and parts of a variable. What I have is suggested is allowing > it to create/initialize the query target of a variable as well. This > concept is independent of the language and where possible we should use > Infoset to describe it. > > - Chris > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Monday, May 02, 2005 1:55 PM > To: Francisco Curbera > Cc: chris.keller@active-endpoints.com; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 11 - Proposal For Vote > > I find the proposal problematic because it is defined using XPATH > semantics. This means that anyone using a language other than XPATH will > no longer have any normative BPEL behavior to depend on and will be in > uncharted waters. While I agree that aspects of this proposal should be > XPATH specific I believe it's higher level requirements must be > expressed using the infoset so that its semantics will apply regardless > of what expression language is used. > > Yaron > > Francisco Curbera wrote: > > I like this. I think it deals with the key scenarios that motivated issue > > 11, while creating essentially no new legacy. > > > > Paco > > > > > > > > > > > > > > > > > "Chris > > Keller" > > > > > > > <chris.keller@active-end To: > > <wsbpel@lists.oasis-open.org> > > > > > points.com> cc: "'Ugo > Corda'" > > <UCorda@SeeBeyond.com> > > > > Subject: [wsbpel] > Issue > > 11 - Proposal For Vote > > > > 04/28/2005 05:09 > > PM > > > > > > > Please respond > > to > > > > > > > > > chris.keller > > > > > > > > > > > > > > > > > > > > TC Members, > > > > As promised during yesterday's conference call here is my alternate > > (amendment) to the Issue 11 Proposal. > > > > Regards, > > Chris Keller > > > > -------------------------------------------------------------------- > > > > Proposal: The most requested form of data manipulation not currently > > covered > > by <copy> is the ability to incrementally create new complex messages in > > order to invoke services or reply from a process. This proposal suggests > > we > > add a create attribute to the existing query element. When this option is > > set to "yes" and the query does not exist then the path will be created > > (note if the path exists there is no need to create it and it is always > > used > > regardless of the state of this attribute). > > > > <query queryLanguage="..."? create="yes|no"?>...<query> > > > > When the create option is enabled and the target query is using the > > BPEL/XPath binding the query will have the following restrictions: > > > > 1 - The path must use the abbreviated form. > > 2 - The path must not use '//' as that can lead to a non-deterministic > > path. > > 3 - Predicates will be limited to integer values, which in XPath indicates > > a > > child number within the context. In addition the EII indicated by the > > integer value must either exist or be at most one higher than the last > > child > > EII of that name within the parent. > > > > If these conditions are not met a compliant implementation MUST throw a > > bpws:createFailure fault. > > > > > > Examples > > -------- > > > > <copy> > > <from><literal>Widget1</literal></from> > > <to create="yes" variable="PurchaseOrder" part="PODetails"> > > <query create="yes"> > > /PODetails/po:items/po:item[$counter] > > </query> > > </to> > > </copy> > > > > When used against the following document with a counter value of 2 (note > > XPath child selection counters start at 1 not zero) will produce a > > bpws:createFailure. > > > > <PODetails/> > > > > > > However if used against a starting document of the form: > > > > <PODetails> > > <po:items xmlns:po="..."> > > <po:item>Widget0</po:item> > > </po:items> > > </PODetails> > > > > Will produce: > > > > <PODetails> > > <po:items xmlns:po="..."> > > <po:item>Widget0</po:item> > > <po:item>Widget1</po:item> > > </po:items> > > </PODetails> > > > > > > Newly created nodes are always appended as the next child of a parent. > > Since the incremental build-up is the most important case let's not try to > > do a general purpose transformation language, if someone needs a new > > ordering or needs to remove an element they can create a new variable by > > combining assigns in the right order from an existing variable. > > > > Before: > > > > <PODetails> > > <po:shippingInfo> > > Some Address > > </po:shippingInfo> > > </PODetails> > > > > After execution of the sample <copy> with a counter value of 1: > > > > <PODetails> > > <po:shippingInfo> > > Some Address > > </po:shippingInfo> > > <po:items xmlns:po="..."> > > <po:item>Widget1</po:item> > > </po:items> > > </PODetails> > > > > > > Attributes will also be created through this mechanism, the following is > an > > example for attribute creation: > > > > <copy> > > <from><literal>10</literal></from> > > <to create="yes" variable="PurchaseOrder" part="PODetails"> > > <query create="yes"> > > /PODetails/po:items/po:item[$counter]/@amount > > </query> > > </to> > > </copy> > > > > Before: > > > > <PODetails/> > > > > After execution of the sample <copy> with a counter value of 1: > > > > <PODetails> > > <po:items xmlns:po="..."> > > <po:item amount="10"/> > > </po:items> > > </PODetails> > > > > > > ------------------------------------------------------- > > > > What this proposal does: > > > > 1 - Handles the ability to assign to new locations, which is what the > > original issue 11 description states. > > 2 - Doesn't go into xupdate or generalized transformations (insert, > append, > > remove, update type operations), which has been the black hole of issue > 11. > > 3 - Easy to describe within the context of the current copy operation > text. > > 4 - Assuming resolution of issue 147 this would enable for each to collect > > result sets utilizing the index variable part of the 147 proposal. > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]