Hi Alex,
> If someone can come up with another precise
term other than "syntax
token", please feel free to the suggest.
I was not questioning the use of specific term "syntax token". I
am suggesting that we need to clearly identify what we mean in the
context of an extemtion. E.g. "An attribute or element qualified by a
"namespace" identified in an <extension> element ?"
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).
Agree. Though I would prefer to state it the other way. An extension
element MUST NOT be added unless the process definition uses an
extension defined in the associated namespace. Why make the associated
logic be loaded when they extension is not used at all?
- extension syntax token MUST NOT "leak"
their semantics outside the subtree
This is where I have an issue. I think we should leave it in the
domain of the definition of the specific extension. I don't see the
real need for adding any such constraints. The subtree domain is very
subjective and varying with a specific extension (as you clarify below
also) and hence I don't see a way for us to define this formally. E.g.
an extension element that occurs at the top of a <scope> may be
applicable to the entire scope or just to that element alone with no
applicability to anything else in the scope etc. No need to say
anything here IMO.
Regards, Prasad
Alex Yiu wrote:
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
|