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 [1]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 [2]XML Schema (which speaks of assembling schema documents) and [3]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

References

Visible links 1. http://www.w3.org/TR/2005/WD-wsdl20-20050803/#modularize 2. http://www.w3.org/TR/xmlschema-1/#layer2 3. http://www.w3.org/TR/wsdl#_style