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:]
> Sent: Monday, May 02, 2005 1:55 PM
> To: Francisco Curbera
> Cc: ;
> 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:
> > <>
>
> >
> > points.com> cc: "'Ugo
> Corda'"
> > <>
> >
> > 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
>
>
>
>
>
