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


Simon,
I understand the questions raised but would (politely) suggest that 
everyone review the many, many emails on the Issue 11 resolution 
including why language below was specified.  In summary:

    * Many questions were raised about atomic assign, optimizing for
      isolated scopes and BPEL variable access.
    * The discussion continued (and evolved) around XSLT-based
      declaration of BPEL variables:
      http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00043.html
          o Such as:

        ....Leave Proposed XSLT-based Declaration of BPEL Variables
        This is what was proposed last week. This depends on name
        matching between the style sheet's global parameters and
        in-scope BPEL variables.
        Advantages:
            * Less verbose
            * Conforms to DRY principle. Adding or removing a BPEL
        variable from the XSL style sheet requires a single change to
        the style sheet only..

        Disadvantages:
            * Static analysis of variable dependencies depends on the
        assumption that style sheets are named using literals, and the
        named style sheet doesn't vary (i.e, the URI used to name the
        style sheet indicates an non-varying resource).
            * Decreased readability

        Note that analysis of dependencies is trivially accomplished at
        run-time, even if style sheet names are dynamically determined.
        If style sheet names are not dynamic (that is, they are
        literals) then this analysis can be done earlier.

        Worrying about dynamic changes (during run-time) to resources
        indicated by URIs is a problem that applies to WSDL, XML Schema,
        and BPEL already; our specification is deliberately silent about
        how such issues are handled (leaving it to implementations to
        address this as they wish)....

    * Irrespective of Issue 11, the discussion evolved to whether
      dynamic changes at runtime were a general issue in WS-BPEL
      (questions from Chris Keller and others inputting such as Ron
      Ten-Hove quote below). Note that the this text was deemed
      appropriate irrespective of whether BPEL addresses this in general
      (to your point on why to delete the text, which was discussed in
      detail previously):

    "What do we have then? We have exactly the same situation we have
    with other "inclusion" mechanisms already used by WS-BPEL, WSDL, and
    XML Schema. A URI (relative or absolute) is used to indicate an
    "included" resource. What if a WSDL document changes a message type,
    or a message property? WS-BPEL never addresses the issue of what
    happens if a resource indicated by aURI changes. Why should this
    particular piece of WS-BPEL (assuming it is adopted) be any
    different? Put another way, how is any different than WSDL?"

          o Here are two references include:
            http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00045.html,
            http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00050.html
    * The proposal was updated:
      http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00047.html
    * Caching and management was also touched upon: 
      http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00056.html
    * Alex Yiu proposed some solutions to resolve when the XSLT is
      analyzed by BPEL processors and requested some inclusive language
      to allow but not require support for runtime updates to
      stylesheets:
      http://lists.oasis-open.org/archives/wsbpel/200510/msg00057.html
    * The proposal was updated (and ultimately) approved:
      http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200510/msg00066.html

My point in providing this summary is to indicate:

    * We review the significant previous discussion that clearly
      describes what the implications were and why this text was updated.
    * We remain consistent with our previous model that features and
      specific resolutions not be revisited as the current effort is an
      exercise in clarifying the specification rather than rehashing
      previous issues (of which this one was significant and vetted in
      detail).

I realize you may have just joined the TC when this was opened, so 
please take this summary in that context. Regards.

>moser: Hi all,
>
>as discussed in the Call today, I move to vote on my submitters proposal to
>remove the text mentioned below from section 8.4
>
>Status: received
>Date added: 25 Mar 2006
>Categories: Other specifications
>Date submitted: 24 March 2006
>Submitter: Simon Moser
>Description: The Text 8.4 about the dynamicity of XSLT should be removed
>
>
>In Section 8.4, there is some text (which used to be a footnote):
>
>
>      Style sheets associated with a process (through its doXslTransform
>      invocations) are considered part of the process definition, and in
>      most situations would not change at run-time. 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).
>We (TC at f-t-f, Stuttgart) think that talking about dynamically changing
>of XSLT artifacts is out of scope for the specification, since we do not
>talk about dynamically changing WSDL or XSD files that are referenced from
>the process, too.
>
>
>Cheers
>/Simon
>--------------------------------------------------
>Simon Daniel Moser, M.Eng.
>Business Process Solutions Development 1
>IBM Boeblingen Laboratory
>Schoenaicherstr. 220, 01/086
>D - 71032 Boeblingen
>Tel.: +49 - 7031 - 164304
>IP Telephone Number (ITN): 39204304
>email: smoser@de.ibm.com
>
>Rule of thumb #3459835478: when you find yourself typing/copying the same
>thing more than twice in a row, redesign or re-implement. No excuse
>possible.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>




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