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
Yaron Y. Goland wrote:
Change:
However, documents (or namespaces) imported by an imported document (or
namespace) are no considered to be transitively imported by the
process.
To:
However, documents (or namespaces) imported by an imported document (or
namespace) are not considered to be transitively imported by the
process.
The lack of transitivity can cause some interesting issues. For
example, a document D1 could define a type called a:Type. But a:Type's
definition could depend on another type called another:Type which is
defined in document D2. D1 could include an import for D2 thus making
another:Type's definition available for use with a:Type.
Now imagine a BPEL process refers to a:Type and imports one and only
one document, D1. By importing D1 the BPEL process can legally refer to
a:Type. But, the BPEL process could not refer to another:Type even
though D1 imports D2. This is because transitivity of import is not
supported by BPEL. Note, however, that D1 can still import D2 and
a:Type can still use another:Type in its definition but the BPEL
process cannot directly refer to another:Type. In order to allow the
BPEL process to refer to another:Type it would be necessary for the
BPEL process to directly import document D2.
Francisco Curbera wrote:
Hi Yaron,
That is fine with me, although I am not completely sure what possible
confusion you have in mind. Would you mind writing the clarification
text
you think that paragraph needs?
Paco
"Yaron Y.
Goland"
<ygoland@bea.com> To:
Francisco
Curbera/Watson/IBM@IBMUS
cc:
wsbpel@lists.oasis-open.org
08/03/2005 11:12 Subject: Re: [wsbpel]
Issue 88 - Proposal to vote
AM
Please respond
to
ygoland
I like the change.
In the last sentence I think you want to say "not" rather than "no". I
also think this sentence itself needs some expansion because a naive
reader would think this means that imported WSDLs or Schemas can't
import anything themselves. When what we really mean is that IF an item
is required by BPEL THEN it MUST be directly imported but that imported
item could itself depend on other items that were transitively
imported.
I know this distinction has caused confusion in other standards and I
think we should make it painfully clear in our standard.
Thanks,
Yaron
Francisco Curbera wrote:
>
>
> Hi Yaron,
>
> I added the following to make that case more explicit.
>
> "Observe that according to these rules, it is permissible to have
an
import
> element without namespace and location attributes, and only
containing an
> importType attribute. Such an import element indicates that
external
> definitions of the indicated type are in use which are not
namespace
> qualified, and makes no statement about where those definitions
may be
> found."
>
>
> Updated proposal follows:
>
>
> The <import> element is used within a WS-BPEL process to
explicitly
> indicate a dependency on external XML Schema or WSDL definitions.
Any
> number of <import> elements may appear as initial children
of the
<process>
> element, before any other child element. Each <import>
element contains a
> mandatory and two optional attributes.
>
> - namespace. The namespace attribute specifies an absolute URI
that
> identifies the imported definitions. This attribute is optional.
An
import
> element without a namespace attribute indicates that external
definitions
> are in use which are not namespace qualified.
>
> - location. The location attribute contains a URI indicating the
location
> of a document that contains relevant definitions in the namespace
> specified. The location URI may be a relative URI, following the
usual
> rules for resolution of the URI base (XML Base and RFC 2396). The
location
> attribute is optional. An import element without a location
attribute
> indicates that external definitions are used by the process but
makes no
> statement about where those definitions may be found. The
document
located
> at the location URI MUST identify the definitions it contains
with a URI
> matching the URI indicated by the namespace attribute.
>
> - importType. The importType attribute identifies the type of
document
> being imported by providing an absolute URI that identifies the
encoding
> language used in the document. The value of the importType
attribute MUST
> be set to "http://www.w3.org/2001/XMLSchema" when importing XML
Schema
1.0
> documents, and to "http://schemas.xmlsoap.org/wsdl/" when
importing WSDL
> 1.1 documents.
>
> Observe that according to these rules, it is permissible to have
an
import
> element without namespace and location attributes, and only
containing an
> importType attribute. Such an import element indicates that
external
> definitions of the indicated type are in use which are not
namespace
> qualified, and makes no statement about where those definitions
may be
> found.
>
> The presence of an <import> element should be interpreted
as an
> informational hint to the WS-BPEL processor. In particular,
processors
are
> not required to retrieve the imported document from the location
specified
> on the <import> element. Import elements are conceptually
unordered. It
is
> an error if the imported documents contain conflicting
definitions of a
> component used by the importing process definition (as could be
caused,
for
> example, when the XSD redefinition mechanism is used).
>
> A BPEL process definition MUST import all XML Schema and WSDL
definitions
> it uses. This includes all XML Schema type and element
definitions, all
> WSLD port types and message types as well as property and
property alias
> definitions used by the process.
>
> Schema definitions defined in the types section of a WSDL
document which
is
> imported by a BPEL process definition are considered to be
effectively
> imported themselves and are available to the process for the
purpose of
> defining XML Schema variables. However, documents (or namespaces)
imported
> by an imported document (or namespace) are no considered to be
transitively
> imported by the process.
>
>
>
>
>
>
>
>
>
>
>
>
>
> "Yaron Y.
> Goland"
>
>
> <ygoland@bea.com> To:
Francisco
> Curbera/Watson/IBM@IBMUS
>
> cc:
> wsbpel@lists.oasis-open.org
>
>
> 08/02/2005 12:31 Subject: Re:
[wsbpel]
> Issue 88 - Proposal to vote
>
>
> PM
>
>
> Please respond
> to
>
>
>
> ygoland
>
>
>
>
>
>
>
>
> As per the discussion on the last call there should be language
> explicitly defining what it means to have an import without a
namespace
> or a location. I'm not arguing the case itself, just that it is
odd
> enough that an explicit description of its semantics seems called
for.
> Thanks,
> Yaron
>
> Francisco Curbera wrote:
> >
> >
> > This is the proposal for closing issue 88.
> >
> > Replace the text of Section 6.4, starting on the second
paragraph by
the
> > following.
> >
> >
> > The <import> element is used within a WS-BPEL process
to explicitly
> > indicate a dependency on external XML Schema or WSDL
definitions. Any
> > number of <import> elements may appear as initial
children of the
> <process>
> > element, before any other child element. Each
<import> element
> contains a
> > mandatory and two optional attributes.
> >
> > - namespace. The namespace attribute specifies an absolute
URI that
> > identifies the imported definitions. This attribute is
optional. An
> import
> > element without a namespace attribute indicates that
external
> definitions
> > are in use which are not namespace qualified.
> >
> > - location. The location attribute contains a URI
indicating the
> location
> > of a document that contains relevant definitions in the
namespace
> > specified.
> > The location URIs may be a relative URI, following the
usual rules for
> > resolution of the URI base (XML Base and RFC 2396). The
location
> attribute
> > is optional. An import element without a location attribute
indicates
> that
> > external definitions are used by the process but makes no
statement
> about
> > where those definitions may be found. The document located
at the
> location
> > URI MUST identify the definitions it contains with a URI
matching the
> URI
> > indicated by the namespace attribute.
> >
> > - importType. The importType attribute identifies the type
of document
> > being imported by providing an absolute URI that identifies
the
encoding
> > language used in the document. The value of the importType
attribute
> MUST
> > be set to "http://www.w3.org/2001/XMLSchema" when importing
XML Schema
> 1.0
> > documents, and to "http://schemas.xmlsoap.org/wsdl/" when
importing
WSDL
> > 1.1 documents.
> >
> > The presence of an <import> element should be
interpreted as an
> > informational hint to the WS-BPEL processor. In particular,
processors
> are
> > not required to retrieve the imported document from the
location
> specified
> > on the <import> element. Import elements are
conceptually unordered.
It
> is
> > an error if the imported documents contain conflicting
definitions of
a
> > component used by the importing process definition (as
could be
caused,
> for
> > example, when the XSD redefinition mechanism is used).
> >
> > A BPEL process definition MUST import all XML Schema and
WSDL
> definitions
> > it uses. This includes all XML Schema type and element
definitions,
all
> > WSLD port types and message types as well as property and
property
alias
> > definitions used by the process.
> >
> > Schema definitions defined in the types section of a WSDL
document
which
> is
> > imported by a BPEL process definition are considered to be
effectively
> > imported themselves and are available to the process for
the purpose
of
> > defining XML Schema variables. However, documents (or
namespaces)
> imported
> > by an imported document (or namespace) are no considered to
be
> transitively
> > imported by the process.
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the
OASIS TC that
> > generates this mail. You may a link to this group and all
your TCs in
> > OASIS
> > at:
> >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC
that
> generates this mail. You may a link to this group and all your
TCs in
> OASIS
> at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|