Re: [wsbpel] Issue - 92.6 - Proposal to vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi Prasad,

Thanks for the quick feedback.

Summary of this proposal
There are two normative points that we are trying to add to the spec:

• An extension declared through the <extension> syntax MUST NOT, in and of itself, cause any change to the semantics of a BPEL process (i.e. <extension> declaration itself does not automatically apply any extension semeantics to the BPEL process).
• extension syntax token MUST NOT "leak" their semantics outside the subtree

See more comment inline in GREEN.


Prasad Yendluri wrote:

Hi Alex,

I am trying to reconcile 92 and 92.6 and I am having some difficulty. So an <extension> element that identifies an extension that the process definition utilizes,  via the @namespace on it.  Now the intent seems be to identify where the extension is used (and the scope of it) via this "extension syntax token".

So, in your example I take  'foo:invokeProperty="someNature"' is such a token, where "foo" is the namespace string that corresponds to the namespace identified in the @namespace of an <extention> element.   I take the foo:invokeProperty attribute or the <foo:invokeProperty> element in the <scope> example that follows are just examples.

When a extension @ is added to an element say "A", I would think by default the semantics associated with that extension @ are applicable (and confined to that element A). Nothing out of the ordinary there.

But when an extension element <foo:myExtention element> is added to a scope I would think what the extension is adding (or changing) and the scope of it could be very subjective thing with some, all, no applicability to other activities (or other entities) in the scope.

[AYIU]: I agree with you the scope of the extension application can vary from one entension to another. That's why I used the word "potentially" in the example description: "can be potentially applied to all <invoke> activities"

So the assertion
" the "foo:invokeProperty" extension element can be potentially applied
to all <invoke> activities within the <scope> activity where the extension element are
attached to."  may or may not be true. Why <invoke> activities only for example?

[AYIU]: I am not sure I understand your "why" question. Do you mean we should other activites to the example for better clarity?

I am not sure if you were just illuminating  the issue and illustrating the possibilities but, it is not clear to me what exactly you are proposing that we add to the spec here?

[AYIU] As you said, I am just using those two examples to illustrate the possibilities. :-) ... NOT particularly targeting <invoke>. There are two normative points that we are trying to add to the spec:

• An extension declared through the <extension> syntax MUST NOT, in and of itself, cause any change to the semantics of a BPEL process (i.e. <extension> declaration itself does not automatically apply any extension semeantics to the BPEL process).
  
• extension syntax token MUST NOT "leak" their semantics outside the subtree

The extension syntax token concept is very confusing and needs to be formally introduced. AIUI by merely qualifying an attribute or element with the namespace identified in an <extension> element in the <extensions> section, one identifies that attribute or element as an extension. I don't see the real need for this new concept of extension syntax tokens and their applicable sub-tree etc.

I would rather leave the semantics of a specific extension to the definition of such extension rather than us adding some constraints in advance at the spec level.

[AYIU] Well ... from a programming language / compiler background, "syntax token" is a relatively well understood phrase. (just like "operator" and "operands"). And, the phrase "extension syntax token" is merely a phrase to emphasize the differentiation syntax part from the semantic part. This differentiation is more important as illustrated in the second example. (i.e. the application point (scope) of syntax and application points (invoke) of semantics are different)

If someone can come up with another precise term other than "syntax token", please feel free to the suggest.

We are leaving the semantics of a specific extension to the definition of such extension. There are a lot of rooms for extension definition to fill in.  We are just adding the above two normative points. Because, if we allow the opposite of these points to happen, the extension syntax will become too funky. That's the motivation behind this issue.


Thanks!


Regards,
Alex Yiu

Regards, Prasad

Alex Yiu wrote:

Hi all,

Here is the proposal to vote for Issue 92.6.  (attached PDF file)
Thanks!

Regards,
Alex Yiu