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 88 - Proposal to vote


    I am having doubts about the need for non-transitive import. Your example [1] illustrates something that is discussed clearly in WSDL 2.0. The use of <include> and <import> in WSDL are mechanisms to divide whole, complete, internally consistent logical service descriptions into physically separate modules. This separation is very pragmatic: it facilitates composition of service descriptions from physically separate pieces.

    Assuming WSDL 2.0 is consistent with XML Schema (which speaks of assembling schema documents) and WSDL 1.1 (which describes using import to modularize descriptions) in this regard, I think that non-transitive import is clearly contrary to the intent of these specifications. BPEL must deal with whole, complete, consistent service descriptions (down to the portType/interface level). This requires transitive import to properly reconstitute the logical service description.

    Put another way, why should how a service description (or schema) is divided into physical modules affect BPEL's perception of the logical service (or schema) described? Should remodularising a service description (without affecting the logical service description) cause a previously valid BPEL process definition to become invalid?

    The second example [2], showing an internally inconsistent service/schema description, clearly illustrates one of the hazards of modularising service descriptions. A robust implementation of a Schema or WSDL processor must obviously guard against multiple definitions of the same component (as opposed to multiple includes/imports of the same document).


Alex Yiu wrote:

Hi, Yaron,

I understand in a number of specification "import" are specified as non-transitive.
However, can you point me to related text in WSDL 2.0 spec, XQuery and XML Schema spec? Because, I want to make your example are consistent with their semantics. (I tried to locate related text ... no luck so far ...)

I have some more questions based on the following situation:
  • A BPEL process imports S1.
  • S1 imports S2.
  • S2 defines bar:typeX and bar:typeY.
  • S1 defines foo:type1 which makes uses of bar:typeX in some of sub-element defintion.

(a) It is very clear to me that the BPEL process should not be able to have access to bar:typeY.
(b) It is also clear to me that the BPEL process should not be able to declare variable based on bar:typeX.
(c) However, I am not 100% sure that the BPEL process definition cannot refer to bar:typeX in an (XQuery) expression. For example, consider this expression
    count( $type1Var//*[. instance of element(*,bar:typeX)] )
       (counting how many sub elements of "bar:typeX" within "type1Var")

Another dimension of question is:
  • Another import for S3 was added to the same BPEL process.
  • S3 imports S2b
  • S2b defines "bar:typeY" which share the same QName but conflicting definition when compared with "bar:typeY" in S2.
Note: "bar:typeY" is not used in BPEL process. Should we allow some pessimistic error raising? If not, I can forsee that people will be caught by surprise, if they add an element definition based on "bar:typeY" in S1 / S3 and the BPEL implementation flag an error at that time.


Alex Yiu

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