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 - why <copy create="yes"> is instrincally interwined with XPath


I agree with yaron, that the /copy/to/query@create model may not apply to all expression languages. For example a xquery-based from may always produce an infoset which is to replace the destination (which ponts to a part only). That way it might be an good idea to have something like "<xpath  crate=boolean>" instead of <query queryLanguage="xpath">, becausde an extensin would use something like <ext:varselector name=string> and has no need/use for create attribute. 


-----Original Message-----
From: Francisco Curbera [mailto:curbera@us.ibm.com]
Sent: Wednesday, May 11, 2005 3:32 PM
To: Alex Yiu
Cc: Alex Yiu; chris.keller@active-endpoints.com; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwined with XPath


Yaron's last mail shows that you can use infoset terminology to define the "create=yes" behavior of Chris' proposal, thus putting your claim of XPath dependency in serious doubt. A good way to cut the amount of "hand waving"
would be for you to answer that argument - going beyond the otherwise interesting fact that your XQuery reps feel uneasy about the proposal.


                      Alex Yiu                                                                                                          
                      <alex.yiu@oracle.        To:       Francisco Curbera/Watson/IBM@IBMUS                                             
                      com>                     cc:       chris.keller@active-endpoints.com, wsbpel@lists.oasis-open.org, Alex Yiu       
                      05/10/2005 03:50         Subject:  Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwined     
                      PM                        with XPath                                                                              


This "create" feature is defined in the BPEL base spec, not in an expression-language-specific binding extension specification outside of this TC.

We MUST provide a clear boundary and direction on how this feature works with other expression languages by using some pure XML terminologies and NOT relying terminologies from a particular expression language.

Mentioning a BPEL-base feature in the spec by just showing a definition of its behavior in XPath ... then hand-waving about what should happen in other expression languages ... ask implementators  to make their own best guess how this BPEL feature should behave in other expression languages ...
That is just plain violating the fundamental direction of BPEL spec,  IMHO.

Paco wrote:
"The fact is that many activities already depend on the use of a query language, and that usually means that the execution semantics cannot be fully determine until one language is selected"

Could you actually give some examples to support your claim above?

One key thing to differientiate: "execution details in one expression language" and "execution semantics of the BPEL" are two different things.

Without knowing which expression language is used, of course, we would not know the execution details of an expression language after the execution enters from the BPEL world to the expression language world.

However, the overall execution semantics of BPEL is well-known without picking a particular expression language, including the pre-condition and post-condition of executing expression language. (e.g. the  post condition of executing <assign>/<copy>/<to> must always returns on XML node regardless of which expression language is picked).

As far as I understand, the way that we specify <assign>/<copy> today is expression language-independent. We define its semantics based on expression-language terms.

In our definition of <copy> today, we do NOT need to mention: descendants "//" or  predicate "[]", which are the essential parts of this "create"

(I was trying to mention some political sensitive terms in this email thread. It seems to me that I have no choice but to touch those hidden

If Paco's claim about the fundamental direction and charter of  BPEL TC is true, then one can define a specific feature which we say only how it works in Java / BPELJ in this OASIS TC?  Leave C# binding for other people to specify?

For example:
<variable name="x" ... objectType="anObjectClass"? dataBinding="uri"? /> Add an objectType attribute to allow pointing to an Object Class (And in our spec, we just specify its semantics when it is pointing to a Java class, do not mention what happen in C#.) And, add "dataBinding" attribute to point to a XML-to-Object mapping (And, in our spec, we just define what its means in the JAXB binding world).

Note: I am not saying I am going to define object-features in BPEL. But, if Paco's claim is true and particularly after passing this "create" proposal, then we have precedent cases and putting the above definition in BPEL spec becomes reasonable and legal

Alex Yiu

Francisco Curbera wrote:
      I think we all understand that binding each query language requires
      clarifying many language specific issues; I just don't see how that
      argument plays against the "create" proposal. Alex made specific
      observations about how the particular XPath binding should be
      clarified; I
      don't see anything substantial that would prevent the proposal from
      refined to deal with them.

      If, for example, we need to clarify that only XPath expressions that
      returns a single node are valid, then, well, we have to do that using
      specific language - I don't get what is the big deal. The fact is
      that many
      activities already depend on the use of a query language, and that
      means that the execution semantics cannot be fully determine until
      language is selected, even if the overall general behavior of the
      is common across languages.

      As I sadi before, I think this proposal is our best chance to get
      reasonable done for issue 11. IMO, the only acceptable alternative
      would be
      to close with no change.


                            Alex Yiu

                            <alex.yiu@oracle.        To:

                            com>                     cc:
      wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com>

                                                     Subject:  Re: [wsbpel]
      Issue 11 - why <copy create="yes"> is instrincally interwined
                            05/10/2005 12:58          with XPath



      It is of course possible to come up with a similar semantics in some
      non-XPath languages. (I need to stress that I use the word "similar"
      "some", not "same" and "all")

      But, the question is: How does one come up with one single, portable
      universal description which is applicable to all programming
      languages that
      we can think of?

      The BPEL base specification MUST  provide a universal, clear and
      expression-language-independent description to state:
            what are the expected behavior of this "create" feature
            what expression language patterns are supported and what are
            supported with this feature.

      Without this description, this "create" feature is basically
      to other expression language.

      For javascript, we basically need to re-describe the semantics in
      some sort
      of Javascript terminology by saying something like:

            getElement("a") should return one node, while
            returns zero node.
            [Disclaimer: I am no Javascript expert. My terminologies used
            are probably wrong. Let me switch to Java and XQuery for other

      Chris, few questions for you (some of them are already stated in my
      previous email) before we move forward:

      How do you resolve "Parent Location Ambiguity" problem that I stated
      in my
      previous email without referencing to any XPath terminology? How do
      resolve that problem with an expression-language independent

      Even if we stay within the pure XPath world, it was not clearly
      stated that which XPath expression patterns are supported and which
      are not
      supported. If not supported, why?

      Can we support "/abc//def/ghi[3]", as long as "/abc//def" returns one
      element node? If not, why?
      Do we support "/abc/def/ghi[@abc='fff'][3]"?
      Do we support "/abc/def[@abc='fff']/ghi[3]"? If not, why?

      And, how do you describe what XPath expression patterns are supported
      not supported without hardwiring your proposal to XPath terms and
      And, did you already use quite a few of XPath terms in your proposal
      to do

      Instead of covering the infinite universe of programming languages,
      you come up with a single, universal but clear description to at
      cover the following cases?

      (1) someone uses Java with JAXB embedded within BPEL:



      How do we say:
      "javaVariableForCollectionType.getBooks().getBook().get(3)" return
      javaVariableForCollectionType.getBooks().getBook()" return a non-null
      java.util.List object?
      WITHOUT referencing to Java terminologies?

      (2) someone uses XQuery embedded within BPEL

      { (for $b in $collectionTypeVar1/book
        where $b/price > 200
        order by $b/price ) }[3]

      Is the "where" and "order by" clause in XQuery supported, when this
      "create" feature is used?

      Please note: XPath does not have the order-by capabilities, while

      Another important note:

      NOT All programming languages have the same XML capabilities. Even
      one programming language, there may be multiple ways to access XML

      Example #1: There are other ways to expose XML data in Java other
      JAXB. How about just pure DOM API?

      Example #2: Javascript with E4X extension has more XML capabilites
      than the
      original javascript.

      Here is an example of E4X syntax: "order.item.*[1]". Is that


      Alex Yiu

      Chris Keller wrote:
            Hi Alex,

            <to variable="x" part="y">
               <query create="yes" queryLanguage="jscript">

            A context for this script execution would know create was
      turned on
            and then it would create the 10th element called "b" under "a"
      if it
            did not exist and return the new "b" element.  If create was
            turned on it could throw a fault.

            Thereby the "create" could be applied to a non-xpath language
      if the
            binding makes it so.

            - Chris

            From: Alex Yiu [mailto:alex.yiu@oracle.com]
            Sent: Monday, May 09, 2005 9:46 PM
            To: wsbpel@lists.oasis-open.org
            Cc: Alex Yiu
            Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is
            instrincally interwined with XPath

            Hi all,

            As I mentioned in the last conf call, here are details on why
            create="yes"> is instrincally interwined with XPath - i.e. no
            feasible way to define this feature in an expression-language
            independent fashion.

            Summary of why <copy create="yes"> is a bad idea:
                  It is intrinsically XPath dependent (more details are
                  below), while BPEL  itself should be expression language
                  <copy> itself is somewhat schema-aware [See
                  mismatchedAssignmentFailure], while "create" version of
                  is not:
                        As the new node will just always be appended to the
                        parent, regardless of the related schema design, as
                        current proposal stands.
                        The current form <copy> itself is the pure
                        logic, one can compare the XSD type info associated
                        from-node and to-node, when XPath 2.0/XQuery 1.0
                        model is used. If mismatched, it can trigger
                        mismatchedAssignmentFailure fault. However, for the
                        "create" version, this feature is lost. That
      creates some
                        hidden and profound asymmetry, which are surprising
                  The create version of <copy> in the standard is NOT
                  schema-aware, it is almost useless. And, customers
                  force vendors to do add sort of schema tricks. It defeats
                  whole point of standardization. It is a very slippery
                  Bad for standardization.

            Details of XPath-Only / XPath-Dependent Concern

            Parent Location Ambiguity

            The proposal says: "Newly created nodes are always appended as
            next child of a parent."
            However, it does not address one big ambiguity issue: Where is

            Consider this example:

                <def id="d1"> <ghi id="g1"> </def>
                <def id="d2"> <ghi id="g2"> </def>

            /abc/def/ghi[1] points to "g1"
            /abc/def/ghi[2] points to "g2"

            Now, if someone tries to use this "create" feature to copy to
            "/abc/def/ghi[3]", which <def> is the parent? "d1" or "d2"????

            One thing the proposal SHOULD say is: by "popping off" the
            bottom-most-XPath-child axis token in XPath expression parse
            (i.e. "/abc/def/ghi[3]" => "/abc/def"), the resultant XPath
            expression must be evaluated to be ONE single element node.
      Then, it
            solves the ambiguity of parent location. This is a MUST-HAVE

            Please note that: I underlined some of the terms above.
            those terms are extremely XPath specific. This MUST-HAVE
            clarification make this feature become completely

            If one wants to standardize the "create" feature in BPEL spec,
            MUST give the equivalent, crispy clear and portable terms of
            underlined text for other expression languages and
            technologies. E.g. XQuery 1.0, XPath 2.0, Java (with or without
            ... and with or without SDO), C#, Javascript (with or without
            extension), SQL, SQL/XML ... (I consider that

            "Fuzziness" of XPath Expression Subset Definition

            Also, its current attempt to define the subset of XPath
            are supported by this feature is no where clear enough to be
      put on
            the BPEL spec. As of now, it just tries to excludes 3 cases of
            (1) must use abbreviation form (2) must not use "//" (3) must
            position predicate

            For (1), the proposal does not provide a real good reason on
            restricting to abbreviation form only.
            For (2), why we cannot support XPath "/abc//def/ghi[3]"? As
      long as
            "/abc//def" returns one elment node?
            For (3), is this Xpath "/abc/def/ghi[@abc='fff'][3]" supported?
            about "/abc/def[@abc='fff']/ghi[3]"? The proposal does NOT say

            Loosely (or arbitrarily) clipping off some XPath features off
            support domain does NOT create a portable behavior of this

            I strongly urge that whoever wants to standardize this feature
            (outside of this BPEL TC) should come up with a restricted form
            EBNF Grammar for XPath expression subset. Then, that grammar
            clearly state what XPath subset are supported and what are NOT.
            restricted EBNF Grammar needs to be based on the non-terminal
      in EBNF
            Grammar of XPath 1.0
            (e.g. http://www.w3.org/TR/xpath#predicates )

            Implementation experiences say it even louder ...

            As I mentioned before, we (Oracle) have a similar
            extension feature. We NEVER have the intention to standardize
            XPath-only extension feature in BPEL spec. Because BPEL is
            to expression language independent and BPEL spec is NEVER the
            place to standardize a feature which fudges and breaches the
            border line between BPEL and expression language.

            That is: The semantics of a BPEL construct (<copy
            relies on certain features and behavior of underlying
            language.  And, we cannot find a proper portable description of
            features and behaviors across a wide spectrum of expression
            that can be put into the BPEL spec.

            Also, in our implementation experience of similar features, we
            to play around with XPath parser implementation to achieve that
            functionality. And, that implementation will be NEVER portable
            other expression languages. That again further illustrates that
            "create" feature is by definition XPath-concept dependent.

            As far as I know some other vendors have similar extension
            as well, they have no plan to standardize this XPath-only
            either. Hence, I am not alone in that crowd.


            Alex YIu

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