[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 88 - Proposal to vote
Hi Yaron,
- <import importType="http://www.w3.org/2001/XMLSchema"/> would indicate
there are unqualified (namespace wise) XSD definitions being used in the
process definition. This is essentially similar to what XSD allows.
- I am ok qualifying the requirement to have a matching targetnamespace in
the imported document to be able to capture the whatever means the imported
document uses to identify itself.
- A namespace declaration w/o a location is useful when the namespace is a
well known namespace. My guess is that very often the location is going to
be ignored, so adding the mandatory overhead of including a location does
not seem wise.
- As for the problem of honoring or not a location attribute; the WSDL 1.1
schema issue is a bit misleading. My view is that there is only one valid
schema for each language. otherwise you change the namespace. From that
perspective, WSDL 1.1 authors have accepted the WS-I schema to be the right
one and all other prior versions (there were 2!) are deprecated. This is of
course very confusing, but it is the unfortunate consequence o WSDL's
original sin's and early success. I would not think we should design BPEL
to deal with those anomalous cases.
- As for the use of schema redefinition, I am no XSD expert but my
understanding is that in XSD redefinition has pervasive effects in that it
compeltely replaces the original. So assuming that two redefinitions apply
simultaneously is just an ambiguous situation that the process author needs
to clarify since only one will be applied in the end. This is form the
Schema spec:
Note: The pervasive impact of redefinition reinforces the need for
implementations to adopt some form of lazy or 'just-in-time' approach to
component construction, which is also called for in order to avoid
inappropriate dependencies on the order in which definitions and references
appear in (collections of) schema documents.
- I agree we should adding a clarification about the use of XSD definitions
from imported WSDL files.
Paco
"Yaron Y. Goland"
<ygoland@bea.com> To: Francisco Curbera/Watson/IBM@IBMUS
cc: wsbpel@lists.oasis-open.org
04/05/2005 01:07 Subject: Re: [wsbpel] Issue 88 - Proposal to vote
AM
Please respond to
ygoland
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
>
---------------------------------------------------------------------
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]