I have to point you to Paco, this area is way out of my domain.
Yaron
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
>
>
>
>
> 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"
>>>
>>>
>>> <>
>>> <mailto:> To: Francisco
>>> Curbera/Watson/IBM@IBMUS
>>> cc:
>>>
>>> <mailto:>
>>>
>>>
>>> 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"
>>> <http://www.w3.org/2001/XMLSchema> when importing XML Schema
>>> 1.0
>>> > documents, and to "http://schemas.xmlsoap.org/wsdl/"
>>> <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"
>>>
>>> >
>>> >
>>> > <>
>>> <mailto:> To: Francisco
>>> > Curbera/Watson/IBM@IBMUS
>>> >
>>> > cc:
>>> > <mailto:>
>>>
>>> >
>>> >
>>> > 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"
>>> <http://www.w3.org/2001/XMLSchema> when importing XML Schema
>>> > 1.0
>>> > > documents, and to "http://schemas.xmlsoap.org/wsdl/"
>>> <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
>
>
