RE: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwin

Alex,

Please don’t place XPath and Java/BPELJ in the same bucket. XPath is a mandated default expression language in BPEL and is a part of the commonly used interoperable XML web services infrastructure. Java has no such status. I understand the point you are making but this analogy does not help.

Overall, if I understand the point you are making, you are saying this:

Queries against an XML document can be satisfied in many ways and are by their nature not deterministic about the structure required in such a document in order to make the query satisfiable. Thus, simply saying “create the required structure if the query is not satisfied” does not work in general, even when the constraint that the query must return a single node is applied (especially because it may return a single node in a specific document but not in all documents).

Is this an accurate reading of the core of your argument? I didn’t think it had primarily to do with Infoset terminology.

All that said, I am with Yaron and Paco in wanting to avoid any major expansion of the data manipulation features in the current version of BPEL. I think something at the “create if missing” level of (apparent) simplicity is all we can contemplate as new functionality in this area.

Satish

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, May 10, 2005 12:50 PM
To: Francisco Curbera
Cc: chris.keller@active-endpoints.com; wsbpel@lists.oasis-open.org; Alex Yiu
Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwined with XPath

Hi,

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" feature.

(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 land-mines)

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

Regards,
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 being

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 XPath

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 usually

means that the execution semantics cannot be fully determine until one

language is selected, even if the overall general behavior of the activity

is common across languages.

As I sadi before, I think this proposal is our best chance to get something

reasonable done for issue 11. IMO, the only acceptable alternative would be

to close with no change.

Paco

                      Alex Yiu

                      <alex.yiu@oracle.        To:       chris.keller@active-endpoints.com

                      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

AM

Chris,

It is of course possible to come up with a similar semantics in some other

non-XPath languages. (I need to stress that I use the word "similar" and

"some", not "same" and "all")

But, the question is: How does one come up with one single, portable and

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 not

      supported with this feature.

Without this description, this "create" feature is basically NON-portable

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 getElement(“b”,10)

      returns zero node.

      [Disclaimer: I am no Javascript expert. My terminologies used above

      are probably wrong. Let me switch to Java and XQuery for other

      examples.]

Chris, few questions for you (some of them are already stated in my

previous email) before we move forward:

[A]

How do you resolve "Parent Location Ambiguity" problem that I stated in my

previous email without referencing to any XPath terminology? How do you

resolve that problem with an expression-language independent description?

[B]

Even if we stay within the pure XPath world, it was not clearly enough

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 or

not supported without hardwiring your proposal to XPath terms and concepts?

And, did you already use quite a few of XPath terms in your proposal  to do

that?

[C]

Instead of covering the infinite universe of programming languages, could

you come up with a single, universal but clear description to at least

cover the following cases?

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

See:

http://java.sun.com/developer/technicalArticles/WebServices/jaxb/index.html

http://java.sun.com/developer/technicalArticles/WebServices/jaxb/CollectionType.java

e.g.:

<to>

javaVariableForCollectionType.getBooks().getBook().get(3)

</to>

How do we say:

"javaVariableForCollectionType.getBooks().getBook().get(3)" return null

while

javaVariableForCollectionType.getBooks().getBook()" return a non-null

java.util.List object?

WITHOUT referencing to Java terminologies?

(2) someone uses XQuery embedded within BPEL

e.g.:

<to>

{ (for $b in $collectionTypeVar1/book

  where $b/price > 200

  order by $b/price ) }[3]

</to>

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 XQuery

has.

Another important note:

NOT All programming languages have the same XML capabilities. Even within

one programming language, there may be multiple ways to access XML data.

Example #1: There are other ways to expose XML data in Java other than

JAXB. How about just pure DOM API?

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

original javascript.

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-357.pdf

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

Thanks!

Regards,

Alex Yiu

Chris Keller wrote:

      Hi Alex,

      <to variable=”x” part=”y”>

         <query create=”yes” queryLanguage=”jscript”>

            getElement(“a”).getElement(“b”,10)

         </query>

      </to>

      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 not

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

      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 provided

            below), while BPEL  itself should be expression language

            neutual.

            <copy> itself is somewhat schema-aware [See

            mismatchedAssignmentFailure], while "create" version of <copy>

            is not:

                  As the new node will just always be appended to the

                  parent, regardless of the related schema design, as the

                  current proposal stands.

                  The current form <copy> itself is the pure replacement

                  logic, one can compare the XSD type info associated with

                  from-node and to-node, when XPath 2.0/XQuery 1.0 data

                  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 to

                  users.

            The create version of <copy> in the standard is NOT

            schema-aware, it is almost useless. And, customers immediately

            force vendors to do add sort of schema tricks. It defeats the

            whole point of standardization. It is a very slippery slope.

            Bad for standardization.

      Details of XPath-Only / XPath-Dependent Concern

      Parent Location Ambiguity

      The proposal says: "Newly created nodes are always appended as the

      next child of a parent."

      However, it does not address one big ambiguity issue: Where is the

      parent?

      Consider this example:

      <abc>

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

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

      </abc>

      /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 tree,

      (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

      clarification.

      Please note that: I underlined some of the terms above. Because,

      those terms are extremely XPath specific. This MUST-HAVE

      clarification make this feature become completely XPath-specific.

      If one wants to standardize the "create" feature in BPEL spec, ONE

      MUST give the equivalent, crispy clear and portable terms of

      underlined text for other expression languages and data-modeling

      technologies. E.g. XQuery 1.0, XPath 2.0, Java (with or without JAXB

      ... and with or without SDO), C#, Javascript (with or without XML

      extension), SQL, SQL/XML ... (I consider that mission-impossible).

      "Fuzziness" of XPath Expression Subset Definition

      Also, its current attempt to define the subset of XPath expressions

      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 XPath:

      (1) must use abbreviation form (2) must not use "//" (3) must use

      position predicate

      For (1), the proposal does not provide a real good reason on why

      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? How

      about "/abc/def[@abc='fff']/ghi[3]"? The proposal does NOT say it

      clearly.

      Loosely (or arbitrarily) clipping off some XPath features off the

      support domain does NOT create a portable behavior of this "create"

      feature.

      I strongly urge that whoever wants to standardize this feature

      (outside of this BPEL TC) should come up with a restricted form of

      EBNF Grammar for XPath expression subset. Then, that grammar will

      clearly state what XPath subset are supported and what are NOT.  That

      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 implementation

      extension feature. We NEVER have the intention to standardize this

      XPath-only extension feature in BPEL spec. Because BPEL is supposed

      to expression language independent and BPEL spec is NEVER the right

      place to standardize a feature which fudges and breaches the clean

      border line between BPEL and expression language.

      That is: The semantics of a BPEL construct (<copy create="...">)

      relies on certain features and behavior of underlying expression

      language.  And, we cannot find a proper portable description of those

      features and behaviors across a wide spectrum of expression languages

      that can be put into the BPEL spec.

      Also, in our implementation experience of similar features, we need

      to play around with XPath parser implementation to achieve that

      functionality. And, that implementation will be NEVER portable to

      other expression languages. That again further illustrates that this

      "create" feature is by definition XPath-concept dependent.

      As far as I know some other vendors have similar extension features

      as well, they have no plan to standardize this XPath-only feature

      either. Hence, I am not alone in that crowd.

      Thanks!

      Regards,

      Alex YIu

wsbpel message