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:
