[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 88 - Proposal to vote
Hi Dieter, Dieter Koenig1 wrote: >IMO, the proposed specification text answers this question: > >- namespace. (...) An import element without a namespace attribute >indicates that external definitions are in use which are not namespace >qualified. > >- location. (...) 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. > >Both cases may apply at the same time. > It is not clear to me how both can apply at the same time. We do not have namespace URI to infer what the definitions and if they are not name space qualified the location URI tells us where to import them from. But if both are missing it is essentially an empty <import> but for the importType, which does not have enough information to import anything. I understand schema allows an empty import <import/> but I don't get the usage scenario? When would we expect a user use such empty import statement in BPEL and what should the processor do? Thanks. >This is consistent with existing approaches; see the note in >http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import >. > >Kind Regards >DK > > Prasad Yendluri > <pyendluri@webmet > hods.com> To > Francisco Curbera > 08.08.2005 23:47 <curbera@us.ibm.com>, > ygoland@bea.com > cc > Please respond to wsbpel@lists.oasis-open.org > pyendluri Subject > Re: [wsbpel] Issue 88 - Proposal to > vote > > > >Paco, 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." >It is not clear to me when one might use such an import and what can BPEL >processor do with such an >import statement. This seems to be a no-op type import statement to me, in >that it is legal from the sytax point of >view but does not really import anything. Do we really need to allow this, >especially with a text in the spec that >explicitly permits it? > >My recommendation would be not to permit such import statements. > >Thanks. > >Prasad > > 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]