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
