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 - 11 - Proposed Resolution for 10/19 meeting


Alex,

    The feedback I have received on the variable dependency determination issue has pretty well split between the two approaches. There seems to be a slightly stronger opinion in favour of simpler syntax (i.e., leaving the doXslTransform function as it is, with only two parameters). Given that, I applied Occam's razor.

    I would like to explore further your assertion that forcing the style sheet name URI to be a literal is not sufficient. It seems to me this presumes that an engine MUST allow for the named style sheet to change during run-time (thus making static analysis of the style sheet's global parameter name insufficient for building optimised isolated and/or serialized data access).

    This sort of situation already exists in BPEL and the languages it depends on (WSDL 1.1, XML Schema 1.0). The BPEL specification is silent about the possibility of such important resources changing dynamically (during run-time), yet inclusion of resources named by means of URI is still used. The underlying assumption is either that:
  • such resources are read once, during the phases of design or deployment, and thus cannot vary at run-time), or
  • such resources can change during run-time, and that engines MAY be able to handle such dynamic behaviour appropriately.
    Every BPEL engine I am aware of falls into the first category. Given the nature of business processes, the second category might be considered rather undesirable! It would certainly make for a much more complex engine implementation.

    Given all that, why are we worrying about XSLT resources varying at run-time?  Or am I missing something here?

-Ron

Alex Yiu wrote:

Hi Ron,

  • Regarding two options listed in your email.
    As of this moment, I still tend to prefer something along option 1.

    For option 2, I guess forcing URI constant is not enough. What needs to be done / declared extra is: the BPEL engine will fetch and store the XSLT at the time of compilation / deployment. Effectively, we are "embedding" XSLT into the BPEL definition at compilation / deployment time. The combination of URI syntax and compile-time fetching may be just a bit too strange for users to handle.

    And, if we adopt pessimistic locking for isolated scope, that will be just too pessimistic.

    I am sympathic about following "DRY" principle for usability. At the same time, we want to perserve isolation semantics in BPEL effectively also.
  • As stated in my previous (offline) email where I suggested something along option-1.

    (a) bpws:doXslTransform('urn:stylesheets:AddToPO.xsl', $PO, 'OutVar', 'FooBar')
    vs
    (b) bpws:doXslTransform('urn:stylesheets:AddToPO.xsl', $PO, $OutVar, $FooBar)

    I mentioned that would be a flip coin issue in terms of syntax variation. Originally, I tend go for (b). After thinking a little bit, I flip coin back to (a). I guess that will be easier for people,  who understand how getVariableProperty() works, to grabs its meaning.  Sorry for the last minute flip-flop.

What do you think?
Maybe, some of us can work on detail text for (a) together?


Thanks!


Regards,
Alex Yiu



Ron Ten-Hove wrote:
Procedural:
The resolution of issue 48 (XML Transform Support), which was closed without a specification change, is hereby rescinded.
Section 9.4: append the following:
The above copy mechanism, when combined with the default XPath 1.0 expression language, cannot perform complex XML transformations. To address this restriction in a portable fashion, a WS-BPEL processor MUST support the bpws:doXslTransform() XPath 1.0 extension function, as described in the following paragraphs.

Function signature: Object bpws:doXslTransform(String, node-set)

where:
  • The first parameter (an XPath String) provides a URI naming the style sheet to be used by the WS-BPEL processor. This must take the form of a string literal.1
  • The second parameter (an XPath node set) provides the source document for the transformation to be performed by the WS-BPEL processor. This set must contain a single EII (i.e. an element node in XPath 1.0 data model); if it does not, the WS-BPEL processor MUST throw a bpws:xsltInvalidSource fault. The single EII as specified by this parameter MUST be treated as the single child of the root node of the source tree for XSLT processing.
  • The result of the function MUST provide the result of the transformation. It will be one of the following infoset items, depending on the XSLT output method employed by the selected style sheet:
    • A single TII (an XPath 1.0 text node), created by the "text" or "html" output methods, or
    • A single EII (an XPath element node that is the single child of the root of the result tree), which is created by the "xml" output method.
The WS-BPEL processor MUST execute the bpws:doXslTransform method such that all of the following apply:
  • The first parameter, naming the style sheet to be used, MUST be used to find the style sheet corresponding to the given URI. This is accomplished in an implementation-dependent fashion. If the style sheet corresponding to the given URI cannot be found, the WS-BPEL processor MUST throw a bpws:xsltStylesheetNotFound fault.
  • The processor MUST perform an XSLT 1.0 transformation, as described in section 5.1 (Processing Model) of the XSLT 1.0 specification, using the named style sheet as primary sheet sheet, the provided source EII as the source document, and the result tree as the result of the transformation.
  • Global parameters (section 11.4 of [XSLT 1.0]) are used to pass BPEL variables to the XSLT processor. XSLT global parameters are matched to BPEL variables by name.2 The names must be restricted to two forms:
        - a variable name (for non-message variables), or
        - a message variable part name using the notation from section 9.2.2 (e.g., MsgVar.Part01).
    The WS-BPEL processor MUST map BPEL variables that are accessible in the scope of the activity containing the bpws:doXslTransform function call to the global parameters declared in the style sheet. A global parameter that does not have a matching BPEL variable name MUST retain its default value, as declared in the style sheet. If an uninitialized WS-BPEL variable is mapped to an XSLT parameter, the WS-BPEL processor MUST throw an uninitializedVariable fault. A WS-BPEL processor MAY warn users of any top-level parameters in the named style sheet not matched by in-scope WS-BPEL variables.
  • Any XSLT processing faults that occur during the transformation MUST result in a bpws:subLanguageExecutionFault being thrown.
Note that because XSLT is a side effect-free language, execution of the transformation cannot (by definition) cause any changes to BPEL variables referred to in the style sheet.

1 The purpose of this restriction is to allow implementations to statically analyse the process (and named style sheets) for variable dependencies.
2 Note that XSLT global parameters must use NCNames to order to match the NCNames used for BPEL variable names; QNames will not match.
Section A (Standard Faults): add the following faults to the table:
Fault Name Reason
xsltStylesheetNotFound The named style sheet in a bpws:doXslTransform function call was not found
xsltInvalidSource The transformation source provided in a bpws:doXslTransform function call was not legal (i.e., not an EII).


bpws:doXslTransform Example
Complex document transformation. A common pattern in BPEL processes involves a sequence of receiving an XML document from one service, converting it to a different schema to form a new request message, and sending the new request to another service. Such documentation conversion is easier accomplished using XSLT, using the doXslTransform function For example:
<variables>
    <variable name="A" type="foo:AType"/>
    <variable name="B" type="bar:BType"/>
</variables>

...
<sequence>
    <invoke ... inputVariable="..." outputVariable="A"/>
    <assign>
        <from>
            <expression>
                bpws:doXslTransform("urn:stylesheets:A2B.xsl", $A)
            </expression>
        </from>
        <to variable="B"/>
    </assign>
    <invoke ... inputVariable="B".../>
</sequence>
In the sequence, a service is invoked, and the result (of type foo:AType) copied to variable A. The assign activity is used to transform the contents of variable A to type bar:BType, and copy the result of that transformation to variable B. Variable B is used to invoke another service.

The style sheet A2B.xsl would contain the XSL rules for converting documents of schema foo:AType to schema bar:BType.

Iterative document construction and BPEL variable access. Suppose that we are constructing a document by repeatedly calling a service, and accumulating the result in an XML variable. The loop might look something like this:
<variables>
    <variable name="PO"     type="foo:POType"/>
    <variable name="OutVar" type="foo:ItemType"/>
</variables>

<!-- ... PO is initialized ... -->
<!-- Iteratively add more items to PO until complete -->
<while>
    <condition>...not done...</condition>
    <sequence>
        <!-- Fetch next chunk into OutVar -->
        <invoke ... inputVariable="..." outputVariable="OutVar"/>
        <assign>
            <from>
                <expression>
                    bpws:doXslTransform("urn:stylesheets:AddToPO.xsl", $PO)
                </expression>
            </from>
            <to variable="PO"/>
        </assign>
    </sequence>
</while>
To allow the XSLT style sheet access to the OutVar variable from the BPEL process, it must contain a global (top-level) parameter with the same name:
<xsl:transform version="1.0"
               xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <!-- OutVar variable from BPEL process; defaults to empty
         item
    -->
    <xsl:param name = "OutVar"><item/></xsl:param>

    ...
</xsl:transform>
The style sheet would contain a template similar to the following, responsible for appending OutVar (the new item) to the existing list of items in the PO variable.
<xsl:template match="item">             <!-- line 1 -->
  <xsl:copy-of select="."/>             <!-- line 2 -->
  <xsl:if test="position()=last()">     <!-- line 3 -->
      <xsl:copy-of select="$OutVar"/>   <!-- line 4 -->
  </xsl:if>                             <!-- line 5 -->
</xsl:template>                         <!-- line 6 -->
This template copies all existing items in the source document (lines 1 & 2), and appends the contents of the BPEL variable OutVar to the list of items (line 3 tests to see if the current node is at the end of the item list; line 4 copies the result-tree fragment from the BPEL variable OutVar to follow the the last item. Thus, if PO has a value of:
<po><item>item 1</item></po>
at the beginning of an iteration of the the above loop, and the <invoke> activity returns a value of <item>FooBar</item>, evaluation of the <from> expression will result in a value of:
<po><item>item 1</item><item>FooBar</item></po>
which, when the BPEL copy activity is complete, will become the new value of the PO variable.




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