[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 88 - Proposal to vote
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" >>> >>> >>> <ygoland@bea.com> >>> <mailto:ygoland@bea.com> To: Francisco >>> Curbera/Watson/IBM@IBMUS >>> cc: >>> wsbpel@lists.oasis-open.org >>> <mailto: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"; >>> <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" >>> >>> > >>> > >>> > <ygoland@bea.com> >>> <mailto:ygoland@bea.com> To: Francisco >>> > Curbera/Watson/IBM@IBMUS >>> > >>> > cc: >>> > wsbpel@lists.oasis-open.org <mailto: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"; >>> <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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]