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, Chris,

The bigger concerns from me are:
  • In your proposal, users has no control where to add the new element, but ALWAYS appending at the end. On the other hand, users have a much better control on where to add the new element in the other proposal.
  • You can state that your XPath binding is NOT schema-aware. But, this feature even does not work well in the simple schema example that I mentioned. That is, this feature is NOT useful enough. I can totally forsee that majority of users will immediately request for this feature to become schema-aware, once we have it standardized non-schema-aware version.

    This is a very dangerous slippery slope. Once we slide into this slope, then we will force ourselves and our product invent something that other standard group (e.g. XQuery-update working group) may be trying to invent now.

    [Just to clarify: I don't want to see the TC spending weeks and weeks to discuss schema details of this feature. To stress it again, if we pass a solution in Issue 11, it should be non-schema-aware. ]

We need to wrap up this TC. I would rather see the whole feature you are describing presents as an extension to <assign>.  Then, people would have more time to mess with schema-aware concept of this feature beyond the lifetime of this TC.


Thanks!



Regards,
Alex Yiu




Chris Keller wrote:

Hi Alex,

 

I follow the gist of what you are suggesting.  Yes it allows users to create invalid documents (just like Ugo’s proposal).  And yes users can prevent it, how easily for any particular case is arguable.  We should specifically say for our XPath binding that create will not be schema-aware to rule out any misconceptions, and that all appends are driven from the data.  I won’t rule out that other language bindings may be schema aware (or even a 92.6 compliant extension for a schema-aware attribute on assign J).

 

- Chris

 


From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, May 02, 2005 5:05 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

 


Chris,

Thanks for clarification.

Assuming your proposal does not need to undersand the related XSD.

Consider this simple schema:
------------------------

<element name="contact">
  <complexType>
    <sequence>
        <element name="phone" type="p:phoneType"
            minOccurs="0" maxOccurs="unbounded"/>
        <element minOccurs="0" ref="p:address" />
    </element>
  </complexType>
</sequence>

------------------------

Before the assign, "fooVar" has the data has following:
------------------------
<p:contact>
    <p:phone>212-1234567<p:phone>
    <p:address> ... </p:address>
</p:contact>
------------------------

Now, someone tries to copy a second phone number [???] to variable.
------------------------
<assign>
    <copy>
        <from> <p:phone>415-1234567<p:phone> </from>
        <to>$fooVar/p:phone[2]</to>
    </copy>
</assign>
------------------------

If I understand your "always appended" correctly, it seems to me that the data after the copy will look the following?

------------------------
<p:contact>
    <p:phone>212-1234567<p:phone>
    <p:address> ... </p:address>
    <p:phone>415-1234567<p:phone>
</p:contact>
------------------------

instead of:
------------------------
<p:contact>
    <p:phone>212-1234567<p:phone>
    <p:phone>415-1234567<p:phone>
    <p:address> ... </p:address>
</p:contact>
------------------------
????
(Which is invalid XML???)


If my understanding of "always appended" is correct, it seems to me that is a big macro of Ugo's proposal for a special case?
[Sorry mixing some old syntax here ...]
------------------------
<switch>
    <case condition="count($fooVar/p:phone[2])=0">
    <assign>
       <append>
             <from> ... </from>
             <to>$fooVar</to>
       </append>
    </assign>
    <case>
</switch>
------------------------
Is the above (switch+append) logic equivalent to your proposal?

One of my concern about this proposal direction: its syntax seems to give typical users or even BPEL implementator a false hope or an illusion that its implementation is schema-smart.

In reality, this high-level design will actually more likely generate invalid XML. And, it does so without giving users a chance to control the creation location.

To do above "smart copy" correctly to generat valid XML, one would express the following, if Ugo's proposal is adopted.
------------------------
<switch
    <case condition="count($fooVar/p:address)=0">
        <assign>
           <append>
                 <from> $anotherPhone </from>
                 <to>$fooVar</to>
           </append>
        </assign>
    </case>
    <otherwise>
        <assign>
           <insertBefore>
                 <from> $anotherPhone </from>
                 <to>$fooVar/p:address</to>
           </insertBefore>
        </assign>
    </otherwise>
</switch>
------------------------


Thanks!



Regards,
Alex Yiu



Chris Keller wrote:

Hi Alex,

 

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.

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
 
 
 
 



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