[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - Proposal For Vote
I think this group needs to decide if it is interesting in finishing the BPEL 2.0 specification any time soon. Getting these proposals properly re-written into Infoset terminology and then debugging them will take a very long time in a group that is increasingly running out of steam. In fact, I would point out to the group that COPY itself doesn't even work properly yet! Before we run off and extend assign how about we at least get the basic copy operation fully specified? I had previously started some work on this but put it aside when I found I had to write around 10 pages of text to properly cover all the edge cases. This is why Alex and I agreed to not cover COPY in 103. If our goal is to ship this spec soon enough for it to make the next BPEL product release cycles I think we need to just let issue 11 go for now and deal with it on the next cycle. Heck, it could be the first extension to BPEL 2.0 and be released the day after the standard. Fine with me. But I think opening up issues this large when we are supposedly trying to finish up the spec is unproductive. Yaron Alex Yiu wrote: > 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 <mailto:chris.keller@active-endpoints.com> >> *Cc:* ygoland@bea.com <mailto:ygoland@bea.com>; 'Francisco Curbera'; >> wsbpel@lists.oasis-open.org <mailto: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 <mailto:chris.keller@active-endpoints.com>; wsbpel@lists.oasis-open.org <mailto: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]