[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 88 - Import Errata
Some additional relevant reference points from WS-I BP 1.0. 5.1.3 "Although the wsdl:import statement is modeled after the xsd:import statement, the location attribute is required by wsdl:import while the corresponding attribute on xsd:import, schemaLocation is optional". (This is different than what WSDL 1.2 is doing). But it also says: 5.1.4 "R2008 In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint. This means that WSDL processor may, but need not, retrieve a WSDL description from the URI specified in the location attribute on a wsdl:import element because a WSDL processor may have other ways of locating a WSDL description for a given namespace. For example, it may already have a cached or built-in representation, or it may retrieve a representation from a metadata repository or UDDI server". Ugo > -----Original Message----- > From: Ugo Corda > Sent: Friday, December 05, 2003 10:39 AM > To: Francisco Curbera > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 88 - Import Errata > > > Hi Paco, > > I agree with you that the WSDL 1.1 wording is ambiguous. The > phrase "WSDL allows associating a namespace with a document > location using an import statement" seems to imply that the > whole purpose of the import is to establish the document > location. Fortunately WSDL 1.2 is much more clear in this > respect, by stating that the namespace attribute is required > and the location attribute is optional. So the import is > meaningful whether a file location is specified or not. > > Regarding the import itself being optional, WSDL 1.2 is again > much more clear in this respect. It says "Using the import > construct is a necessary condition for making components from > another namespace available to a WSDL description. That is, a > WSDL description cannot refer to components in a namespace > other that the target namespace unless an import statement > for that namespace is present". > > We don't necessarily need to follow the Schema and WSDL 1.2 > directions, but it might be a good idea to conform and say > that our import is also required. > > Ugo > > > -----Original Message----- > > From: Francisco Curbera [mailto:curbera@us.ibm.com] > > Sent: Thursday, December 04, 2003 8:33 PM > > To: Ugo Corda > > Cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 88 - Import Errata > > > > > > > > > > > > > > Hi Ugo, > > > > I think you have spotted an important difference in approach > > that had not > > surfaced before. I think this relates to whether we make > > imports required > > or not - and what "honor" means. > > > > Nothing in WSDL 1.1 says that imports are required (as they are for > > instance in XSD). The only statement made in WSDL 1.1 is that import > > "allows associating a namespace with a location". So the notion of > > "honoring" import is a very vague one: if the association > is not used > > (because we cached the file or whatever) then the import is > > ignored, but > > this does not mean that definitions from that namespace (or > > from namespaces > > not imported) are not processed. External definitions are > > referenced using > > qualified names, and XML namespace mechanisms are there to > > allow unique > > identification - how they are found and retrieved is up to > > each processing > > environment. Import statements just make life a little > > easier by providing > > an associated location. > > > > XML Schema does require an import clause for every external > namespace > > containing definitions. Maybe it then makes more sense to talk about > > "honoring" an import because a processor can rely on > > inspecting imports > > clauses to preprocess all external definitions it depends on, > > instead of > > relying on XML namespace mechanisms. > > > > So I would say that there is a legitimate issue here, but > that it goes > > beyond the strict wording that you mention. I think we need > > to address of > > whether imports are required for every external definition > used by the > > process. I can imagine there will be different opinions. > > > > Paco > > > > > > > > > > > > > > > > "Ugo Corda" > > > > > > <UCorda@SeeBeyond To: > > <wsbpel@lists.oasis-open.org> > > > > .com> cc: > > > > > > Subject: RE: > > [wsbpel] Issue - 88 - Import Errata > > > > 12/03/2003 07:08 > > > > > > PM > > > > > > > > > > > > > > > > > > > > > What happens if an engine chooses not to honor the import? > > > The current text of the BPEL spec states that the BPEL engine > > > is not required to import the files it is pointed at. > > > > I don't think that not importing the files necessarily > > implies that the > > import is not honored. > > > > The original statement in the resolution of Issue 7 was: > > > > "A <bpel:import> location element will be interpreted as a > > hint for BPEL > > processors. In particular, processors are not required to > retrieve the > > imported document from the specified location". > > > > So it only says that the location information is a hint (but > > the import > > statement could still be satisfied by other means). > > > > The statement appearing in the latest draft is more ambiguous: > > > > "The presence of an <import> element should be interpreted as > > a hint to the > > BPEL4WS processor. In particular, processors are not required > > to retrieve > > the imported document from the location specified on the > > <import> element". > > > > Now it is saying that the <import> element itself is a hint. > > Not sure what > > exactly that means. > > > > Ugo > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le ave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]