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

[Prasad Yendluri <pyendluri@webmethods.com>]

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.

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?

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?

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.

Regards, Prasad

Alex Yiu wrote:

Hi all,

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

Regards,
Alex Yiu