[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 11 - Proposal For Vote
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]