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



Hi Ron,

Thanks for the detailed feedback.

I don't have any religious belief on whether BPEL:import should be transitive or non-transitive. I hope my previous examples illustrates there may not that easy to find a clear cut off line between transitive and non-transitive world. Of course, the semantics of a pure transitive import is easy to describe.

I do have a preference that: BPEL import definition would be relatively consistent with WSDL and XSD import. I want to stress the word "relatively". Because, WSDL / XSD are service and data definition languages, while BPEL is a programming language. Some of the requirements are different [as illustrated in 1(c) part of my example].

One thing is clear to me is: Yaron's version non-transitive import is too strict to be used in a programming language [ As described in http://lists.oasis-open.org/archives/wsbpel/200508/msg00026.html ]


Thanks!


Regards,
Alex Yiu


Ron Ten-Hove wrote:
Alex,

    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).

-Ron

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 ...)

[1]
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")

[2]
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.


Thanks!


Regards,
Alex Yiu



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