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 255 - Proposal for vote


All,

    My apologies for jumping in so late into this discussion; I've been on a leave-of-absence.

    If memory serves, the wording in the issue 11 resolution that mentions (but does not mandate) dynamic style sheet changes was added at Alex's request. Given the parameter passing mechanism between the BPEL-domain and the XSLT global parameters, this seemed quite safe. (This is a far different situation than changing imported WSDL or XSD documents!)

    If Alex is happy with softening the wording, but not the intent (and I believe this is what his proposed changes accomplish), then I am quite happy to go along with these changes.

-Ron

Alex Yiu wrote:
The first XPath function parameter, which locates the style sheet, is intended to have the similar semantics as the location attribute of an <import> element. The differences are only in syntax. Style sheets associated with a process (through its doXslTransform invocations) SHOULD be considered part of the process definition, and in
most situations would not change at run-time in a similar manner to WSDL definitions and XML Schemas referenced by an <import> element.  
However, WS-BPEL processors MAY dynamically update associated style sheets at run-time, as long as all requirements of this specification are still met (in particular, the semantics of "atomic" assignment and
serialized scopes). During process run-time, the interface of stylesheet (e.g. its parameters declared) SHOULD be always consistent with the counter part of the WS-BPEL process definition (e.g. parameters passing in).  
  
I'm not sure this last sentence is really necessary. The consequences of a style sheet not being consistent with the global parameter names declared in the doXslTransform invocation are well defined by the global parameter mechanism defined in XSLT 1.0. If the intent is to permit mismatches between the style sheet and the process, then this could be rephrased to be an imperative:
Normally the interface of the style sheet (i.e, its global parameters) will match the global parameters named in the bpws:doXslTransform function invocation that uses the style sheet. For flexibility the WS-BPEL implementation MUST NOT declare an error (either during static analysis or run-time) if the style sheet and the function invocation don't agree on the global parameter names.
If this wasn't the point of the last sentence, perhaps we can omit it entirely?

-Ron


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