OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]