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: Re: [wsbpel] Issue 88 - Proposal to vote


Please see comments below

Francisco Curbera wrote:
> 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.
> 

This means that <import importType="http://www.w3.org/2001/XMLSchema"/>
would be legal. But it is quite literally meaningless. I suspect what 
you intend to say is that namespace MUST have an importType and either 
location or namespace or both.

> 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.
> 

This should only apply if the importType is XMLSchema or wsdl. Other 
imported artifacts defined outside of of the WS-BPEL 2.0 spec may have 
semantics that don't require namespaces.

> 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.
> 

What benefit do we get from explicitly declaring a namespace without a 
location?

> 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.
> 

Works for me

> 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).
> 

I'm fine with this answer. But we should specifically refer to the 
appropriate standards and mandate their use. That will give us some hope 
of portability.

> 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.
> 

Once upon a time there was this note posted to the W3C website called 
WSDL 1.1. It has an appendix that defined a schema and gave it a 
namespace. At a later date another group, WS-I, came up with a new 
schema that wasn't compatible with the WSDL 1.1 schema but kept it in 
the same namespace.

Now imagine that a BPEL engine was written using the schema in the 
original WSDL 1.1 note's schema. And someone comes in with an import 
that uses the WSDL 1.1 namespace but is using the schema from BP 1.1. 
The BPEL import includes a location that points at the BP 1.1 defined 
schema.

But our 'smart' BPEL engine says to itself "Oh gee, there is no need for 
me to retrieve the schema defined at that location because I already 
know the definition for that namespace."

Of course the engine is wrong and the result will be a failed BPEL 
process that is using the wrong schema.

The moral of this story is that when someone says "retrieve this file" 
they mean - RETRIEVE THIS FILE. If the engine chooses to ignore their 
request or cannot honor their request then a static error seems appropriate.

Of course that 'static error' could come in the form of a warning that 
the user can choose to override. BPEL never tells anyone how to serve up 
their errors, just that errors MUST occur.

> 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.
> 

Imagine I have two schemas files, SA and SB, both defining elements in 
the same namespace. Both SA and SB use the XML schema redefine element 
to redefine the same element. What the final value of the redefined 
element turns out to be will depend on the order with which SA and SB 
are processed. Therefore ordering matters and we need to specify 
behavior for it.

> 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.
> 

Where is this unambiguously stated in the spec?

> 
> Paco
> 

Thanks for taking the time to start the process of resolving these issues!

		Yaron

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