[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 88 - Proposal to vote
Yaron, http://www.w3.org/TR/xmlschema-1/#composition-schemaImport has the
following:
---
Note: Since both the namespace and schemaLocation [attribute] are optional,
a bare <import/> information item is allowed. This simply allows
unqualified reference to foreign components with no target namespace
without giving any hints as to where to find them.
---
Therefore, <bpel:import importType="http://www.w3.org/2001/XMLSchema"/> is
consistent with XML Schema.
An imported WSDL/XSD artifact may have or may not have a target namespace.
Whether the location is considered a hint (and therefore optional) is an
orthogonal question.
Kind Regards
DK
"Yaron Y. Goland"
<ygoland@bea.com>
To
18.04.2005 20:43 Francisco Curbera
<curbera@us.ibm.com>
cc
Please respond to wsbpel@lists.oasis-open.org
ygoland Subject
Re: [wsbpel] Issue 88 - Proposal to
vote
Please see below
Francisco Curbera wrote:
> 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.
>
Could you please provide a reference to XSD where this kind of syntax is
allowed? I'm also unclear as to the benefit of allowing a declaration
that says "some schema in some unknown namespace at some unknown
location with some unknown definition is allowed in this BPEL." It seems
preferable that such things simply be left unsaid.
> - 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.
>
Sounds good.
> - 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.
>
Then what purpose does an import statement serve? After all, simply
using an element or attribute from the specified namespace in the BPEL
files makes clear that the namespace is being used. An explicit import
should only be needed if one has actual location information. Or are you
intending toward semantics similar to C header files where one must
declare what is being used ahead of time?
> - 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.
>
Alex is the one with the examples so I'll leave it to him to argue the
point. Personally I'd rather live in the world you describe.
> - 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.
>
In that case we should at least put in a note making it clear that
conflicting redefinitions are an error and (more importantly) that our
import statements are explicitly unordered.
> - 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
>
>
>
---------------------------------------------------------------------
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]