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 - 111 - Extension Syntax should be elegant andin sync with other programming languages

Just want to point out a few things:
  • Some new data and factors are NEWLY discovered, as we discussed the rest of Issue 111. That is: keeping current Issue 111.1 decision will force us suffer from a sub-optimal syntax design for extended activities. Neither [Option-2] nor [Option-3] seems normal or elegant, in my humble opinion. Some of oddities of [Option-3] were already highlighted in the email sent to Danny. The "extensionActivityWrapper" syntax construct is NOT and CANNOT be a true activity in either [Option-2] or [Option-3] cases. That triggers me and Yaron adding [Option-1].
  • In Waldorf F2F, even Paco himself suggested that we might want to park the Issue 111.1 discussion and re-visit this syntax topic again until we have more ideas on  the main Issue 111 (extension activities). (Unfortunately, events did not follow this particular suggestion from Paco. That is my greatest regret in Waldorf F2F).
  • And, the sub-optimal concern is not just my own opinion. I discussed this syntax issue with a bunch of folks from different companies. Most opinions I heard so far are NOT in favor of [option-2] or [option-3]. Of course, I would expect Paco would disagree here.

  • WSDL inspiration? or XML-languages inspiration?:
    • "Annotation" vs "Extension": They are just merely two different symbols pointing to the same concept in different parts of computer world. "Annotation" in Java allowing vendor to change the QoS of a Java method by adding annotation. "Annotation" in XSD allows a RDMBS vendor to embedd processing instruction on mapping XSD to a DB schema. In BPEL, we can add "Extension" to invoke / scope to change its QoS. We can add "Extension" to variable declaration to instruct  the BPEL engine how to persist an XML variable into a RDBMS. If the "Annotation" and "Extension" here are NOT pointing to the same concept, I don't know what would qualify that statement.
    • Other citizens in XML Land: XSD, ASP, JSP, XSLT:
      • WSDL is an service interface description language. It has only ONE extension point per WSDL construct. Hence, the current WSDL design is an elegant solution to the WSDL world.
      • BPEL 2.0 is a programming language that has more than one extension points per construct. And, we allow intermixing elements of different namespace (extension points and standard construct) in no particular order (except the general extension, as wrapped by <extendedBy> in [Option-1]). This is the NOT the same problem that WSDL is trying to solve.
      • The model depicted [Option-1] is MUCH closer to the models used in XSD, ASP, JSP, XSLT when they need to mix element of different namespaces together. If all these 4 products/standards arrive at the similar conclusion, why force BPEL language to be the odd guy away from the mainstream XML population? (I bet all the XML-based tools out there will have an easier time to deal with [Option-1].)
    • I hope we are NOT coerced to believe in a doctrine that one extension model  should rule all extension models in the XML world. Otherwise, we should change ASP, JSP, XSD, XSLT soon.

  • Important clarification: I found one of Paco's statement has some fundamental mis-representation of the original proposal: He said: the proposal "removes general purpose extensibility and replaces it with an annotation model". That is WRONG!!! THERE is NO changes WHATSOEVER in the general purpose extensibility model used by the current BPEL model. We are merely adding <extendedBy> to wrap around the general extension points in BPEL. We added <sources> and <targets> wrappers when we moved from BPEL 1.1 to BPEL 2.0. By adding <sources> and <targets>, the control links model does not change. Only syntax clarity got improved. As it was agreed to add <sources> and <targets>, why adding <extendedBy> wrapper becomes a cardinal sin in some religion?
  • One thing I agree with Paco is: it is a good idea to have a full discussion on this issue before proceeding to a web-ballot. Because, quite a number of people could not attend the Walddorf F2F in person because of the travelling distance or by phone because of time zone difference. We almost did not have quorum at the beginnning of the meeting. And, people attended by phone were generally having tough time to imagine the syntax over the phone. Eventually, most of them voted "abstain" during Issue 111.1 discussion.

All in all, I 100% believe that flushing this out serve the longer term benefits of this TC and BPEL standard. Looking forward to a productive Conf Call discussion tomorrow.


Alex Yiu

Francisco Curbera wrote:
I have already expressed my deep concern about reopening an issue that was
closed after extensive discussion, without any new facts to support a
change.  This is just wrong, a perfect recipe for never getting anythign
done; when can we assume that a closed issue is really closed? There are a
few resolutions that I would love to reverse, but I don't think it is right
for me or anyone else to try to revisit past decisions of the TC w/o
bringing new relevant facts to the table.  So I think the right vote on
this ballot should be a principled one: reject reopening the issue because
that is not how we want this TC to operate.  However, since we are going to
vote again on the proposal we discussed in Waldorf, I've put together a
summary of why we voted the way we did. You can find this below.

I have one more concern: it seems to me that if we do reopen we must allow
for full discussion or existing proposals and also submission of new ones.
Once reopened the TC must have a chance to debate and vote on 111.1 like it
does with any open issue.  This is particularly important given that many
people missed the whole discussion in Waldorf and even those that attended
the f2f may have some trouble recalling the extensive discusion we had

Approved resolution

The approved resolution was to maintain the existing, WSDL-inspired,
general purpose extensibility model and add the provision that whenever the
BPEL spec itself architects extensibility points for a dedicated purpose
(like providing a literal value in a from-spec) a wrapper element in the
BPEL namespace will be introduced to explicitly distinguish it from regular
("standard' or general purpose) extensible content.

We can simply characterize the current model saying that everywhere in BPEL
we allow general purpose extensible elements/attributes unless there is a
good reason to restrict this flexibility. Possible conflicts
(non-deterministic content models) are avoided in the case of architected
extensions using wrapper elements. Wrappers contain extension elements with
semantics that are constrained by the BPEL spec. For example, here is the
case of <from> specs in literal assignments:

  <literal> ... extensible elements provide the literal value to assign ...

Here BPEL architects a "single purpose" extensibility point for providing
literal values to assign, and to that effect we have introduced the
<literal> wrapper with the following semantics: everything it contains is
to be interpreted as a literal data value. The <from> element itself
remains open for general purpose extensions available everywhere else in
the language. Extensible copy is another instance, you an find this in the
issue resolution.

This model is a simplification and consolidation of the one in WSDL 1.1,
which has already been shown to be quite useful; if anything the problem
WSDL 1.1 had was that it did not provide extensibility across the board.
This has been fixed in v2.0, and that is also essentially the same we have
right now in BPEL. I have not yet heard a good reason for getting rid of
it, except for some very debatable subjective statements about pretty/ugly

Original proposal

The alternative that was not accepted and is now again up for a vote
removes general purpose extensibility and replaces it with an annotation
model similar to the one in XML Schema. BPEL elements cannot be directly
extended with extensibility elements or attributes, instead, they can
contain "annotations" that are themselves extensible. Schema itself doesn’t
call that a extensibility model since it is not one, rather it is a good
mechanism for adding documentation and processing instructions. It may look
like a difference in syntax only, but there is a significant difference
between annotating and extending, and many of us believe that a lot of the
power XML gives us is precisely because of extensibility.

I think we can characterize this proposal as saying that nothing is
extensible unless explicitly allowed, but you can annotate things. When we
"authorize" extensibility in an element, it is not generic but constrained
to one specific purpose (like, "every extensible element under a <sequence>
must be an extensible activity"). This is the complete opposite of the
current approach which is to let extensions be used unconstrained unless
there is a good reason not to and goes against what the WSDL experience
tells us about extensions

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