[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 88 - Proposal to vote
This is a proposal for closing issue 88. I propose that we add the following clarifications to the text describing <bpel:import> in Section 6.4: 1. All WSDL and XSD definitions MUST be explicitly imported. 2. The only mandatory attribute on the <bpel:import> element is "importType" of type xs:anyURI, for which the BPEL spec defines two values, indicating the import of WSDL and XSD documents. 3. Imported documents MUST have a targetnamespace matching the namespace attribute in the <import> element, or none if no targetnamespace was specified in the import. 4. "location" and "namespace" are optional. An import w/o namespace indicates that external WSDL or XSD definitions are in use that are not namespace qualified. An import w/o location indicates that external definitions in a certain namespace (or lacking one) are used in the process definition, making no statement about where those definitions may be found. 5. Namespace and importType URIs are always absolute. Location URIs may be relative, following the usual rules for resolution of the URI base (XML Base, RFC 2396). These are my proposed answers to questions in the issue description: Q: Should we use the XML element name 'import'? Import implies that the files that are being pointed to are included in the BPEL definition. But strictly speaking that isn't the case since BPEL does not support in-line WSDL or XML Schema definitions. Shouldn't the name be more descriptive, such as 'associate'? A: Import does not usually imply that files are "included" in the BPEL definition - that is "include" as in XSD and WSDL 2.0; import implies that definitions from the referenced namespaces are used by the importing document. Since that is what we are doing here (albeit crossing XML dialects) I propose we keep the "bpel:import" element name. Fewer new concepts is better. Q:How do we handle relative URIs in import's attributes? What is the base URI against which the relative URIs are resolved? Should we refer to something like XML Base (http://www.w3.org/TR/xmlbase/)? Should we specify that if xmlbase isn't used then the definition of the base URI is engine specific? A: Namespaces should be absolute URIs. I see no reason why locations cannot be relative URIs but we should just accept the usual specification set driving the definition of a URL base (I guess that is RFC 2396 and XML Base), unless there is a reason to go beyond it (which I don't see). Q: 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. But if it fails to import the files then the BPEL definition will not be complete and at some point an error is likely to happen if the imported files contained definitions necessary for the BPEL. Shouldn't a static error be thrown if an engine decides not to honor an import? A: What does "not honoring" the import mean? The import element provides a BPEL processor with information about what WSDL and XSD dependencies to expect. The location is a hint. The BPEL processor may already know (because it is that smart) about all those definitions so it doesn't need to do anything (honor?) about the import. Or it may chose to retrieve from a local cache a the corresponding definitions document, or may even decide to download the file from the location provided. These are all acceptable behaviors. If honor means "actually use the WSDL and XSD definitions from those namespaces, that is a requirement for executing the process anyhow irrespective of import. Q: What happens if two different files import the same definition? Is there any sort of ordering? Does the first or last definition hold? Should this always be a static error? What about collisions from implicit imports versus explicit imports? An implicit import is an import that occurs through a mechanism not specified in the BPEL file itself (e.g. how import worked before we introduced the import XML element). An explicit import is an import specified via an import XML element. A:WSDL as well as XSD allow the same namespace to span multiple documents, which means that two imports for the same namespace (presumably with different location values) do not necessarily constitute an error. I assume the question refers to the possibility of conflicting definitions being found in those documents, but that should be considered a problem with the WSDL or XSD documents themselves, not a BPEL import error. Q: Are the schema values defined in an imported WSDL available for use in BPEL variable types? WSDLs contain a schema declaration section which is used to define WSDL values. Does importing a WSDL mean that any schema values declared in the WSDL are generically part of the 'set' of schema definitions available for use in the BPEL? Not just in WSDL variables but also for use in XML schema variables? A: Yes. Paco
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]