[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:
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. Thanks! Regards, 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 there. 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: <from> general-purpose-extensibity... <literal> ... extensible elements provide the literal value to assign ... <literal> </from> 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 schemas. 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]