This issue has been added to the wsbpel issue list with a status
of "received".
The status will be changed to "open" if a motion to open the issue is
proposed and that
motion is approved by the TC. A motion could also be proposed to close
it without
further consideration. Otherwise it will remain as "received".
The issues list is posted as a Technical Committee document to the
OASIS
WSBPEL TC pages
on a regular basis. The current edition, as a TC document, is the most
recent version of the document entitled in the "Issues" folder of the WSBPEL
TC document list
- the next posting as a TC document will include this issue.
The list editor's working copy, which will normally include an issue
when it is announced, is available at this
constant URL.
Issue - 235 - More import errata
Status: received
Date added: 17 Nov 2005
Categories: Related
standards
Date submitted: 17 November 2005
Submitter: Danny van der
Rijn
Description: Two points that we do not currently cover in our
section on imports that need to be addressed:
- There is no language saying that the schema-for-schemas,
http://www.w3.org/2001/XMLSchema, is implicitly imported. Without it,
everyone is going to have to put the schema on their import list. Most
will do so without a schema location. We should make the implicit-ness
part of the spec. We should also probably disallow <import> of a
schema with targetNamespace http://www.w3.org/2001/XMLSchema.
- There is no statement saying how to treat a WSDL that has a
'types' section that declares types in a targetNamespace which is
different from the targetNamespace of the WSDL elements. May those
types be referenced without an <import> linking the types to a
location? My feeling is that they should not be. If it is required to
use a separate <import> to reference them, what should the
importType be? My feeling is that it should be
http://schemas.xmlsoap.org/wsdl/, but I can see the case being made for
http://www.w3.org/2001/XMLSchema.
Submitter's proposal:
A) Change the paragraph from the Issue 88 resolution
From
- namespace. The namespace attribute specifies an
absolute URI that
identifies the imported definitions. This attribute is optional. An
import
element without a namespace attribute indicates that external
definitions
are in use which are not namespace qualified.
To
- namespace. The namespace attribute specifies an
absolute URI that
identifies the imported definitions. This attribute is optional. An
import
element without a namespace attribute indicates that external
definitions
are in use which are not namespace qualified. The namespace
http://www.w3.org/2001/XMLSchema
is imported implicitly, and therefore MUST NOT be imported. Note,
however, that there is no implicit XML Namespace prefix
defined for http://www.w3.org/2001/XMLSchema.
B) Change the following paragraphs from the Issue 88 resolution
From
Schema definitions defined in the types section of a WSDL
document which is
imported by a BPEL process definition are considered to be effectively
imported themselves and are available to the process for the purpose of
defining XML Schema variables. However, documents (or namespaces)
imported
by an imported document (or namespace) MUST NOT be transitively
imported by
the BPEL processor. In particular, this means that if an external item
is
used by a BPEL process, then a document (or namespace) that defines
that
item MUST be directly imported by the process; observe however that
this
requirement does not limit the ability of the imported document itself
to
import other documents or namespaces. The following example clarifies
some
of the issues related to the the lack of transitivity of imports.
Assume a document D1 define a type called a:Type. But a:Type's
definition
could depend on another type called b:Type which is defined in document
D2.
D1 could include an import for D2 thus making b:Type's definition
available
for use within the definition of a:Type. If a BPEL process refers to
a:Type
it must import document D1. By importing D1 the BPEL process can
legally
refer to a:Type. But the BPEL process could not refer to b:Type even
though
D1 imports D2. This is because transitivity of import is not supported
by
BPEL. Note, however, that D1 can still import D2 and a:Type can still
use
b:Type in its definition. In order to allow the BPEL process to refer
to
b:Type it would be necessary for the BPEL process to directly import
document D2.
To
Schema definitions defined in the types section of a WSDL
document which is
imported by a BPEL process definition and have the same targetNamespace
of the WSDL document are considered to be effectively
imported themselves and are available to the process for the purpose of
defining XML Schema variables. However, documents (or namespaces)
imported
by an imported document (or namespace) MUST NOT be transitively
imported by
the BPEL processor. In particular, this means that if an external item
is
used by a BPEL process, then a document (or namespace) that defines
that
item MUST be directly imported by the process; observe however that
this
requirement does not limit the ability of the imported document itself
to
import other documents or namespaces. The following example clarifies
some
of the issues related to the the lack of transitivity of imports.
Assume a document D1 define a type called a:Type. But a:Type's
definition
could depend on another type called b:Type which is defined in document
D2.
D1 could include an import for D2 thus making b:Type's definition
available
for use within the definition of a:Type. If a BPEL process refers to
a:Type
it must import document D1. By importing D1 the BPEL process can
legally
refer to a:Type. But the BPEL process could not refer to b:Type even
though
D1 imports D2. This is because transitivity of import is not supported
by
BPEL. Note, however, that D1 can still import D2 and a:Type can still
use
b:Type in its definition. In order to allow the BPEL process to refer
to
b:Type it would be necessary for the BPEL process to directly import
document D2.
Schema definitions defined in the types section of a WSDL
document which
is imported by a BPEL process definition and have a different
targetNamespace
than the WSDL document MUST have a separate <import> in order to
be used by the BPEL document. The importType attribute of this import
MUST be http://schemas.xmlsoap.org/wsdl/,
reflecting that the base document is a WSDL document, and not a schema
document.
Changes: 17 Nov 2005 - new issue
To comment on this issue (including whether it should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this message should
automatically send your message to that list), or ensure
the subject line as you send it starts "Issue - 235 -
[anything]" or is a reply
to such a message. If you want to formally propose a resolution to an
open issue, please start the subject line "Issue - 235 - Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the
address for new issue submission is the sender of this announcement).
---------------------------------------------------------------------
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