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
|