OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue 11 - Proposal For Vote


Hi Alex,

 

(1)   The proposal does state that the location of the element creation is an append (…Newly created nodes are always appended as the next child of a parent…).  Sorry if it wasn’t clear, I’ll try to clean that up.

(2)   Only instance data no schema smarts, so one would have to create in the proper order to prevent validation errors.

 

- Chris

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, May 02, 2005 4:18 PM
To: chris.keller@active-endpoints.com
Cc: ygoland@bea.com; 'Francisco Curbera'; wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 11 - Proposal For Vote

 



Hi Chris,

Few bigger questions in my mind about your alternative proposal:
(1) What logic determines the location of newly created elements? (Your current proposal does not say?)
(2) Does the location determination logic involve analysis of both runtime XML instance data and XML Schema (metadata)?
(3) If yes to (2), what varieties of schema design pattern does your current proposal support? All kind of XSDs? Or only a subset of them? What rules define the subset??

[Side Note: Most (if not all) of JAXB implementations (XML-to-Java data access API) today CANNOT deal with all kinds of XSDs. They need to declare what XSD pattern that they do not support. This implementation status also shows that we shall not under-estimate the complexities of XSD.]

If we pass a resolution for Issue 11, I'd rather see a schema-agnostic solution in BPEL standard. ....
That is, a solution that does not try to be smart about dealing with schema. The biggest fear that I have is: we pass a solution that deals with schema patterns some how ... but we only deals with a smart portion of schema design patterns ... The worst is: we even don't which kinds of schemas that we support and which kinds that we do not.

Thanks!


Regards,
Alex Yiu



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 
 
 
 
 
 
 
---------------------------------------------------------------------
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]