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: Issue 111.1 - again

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]