wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsbpel] Issue - 294 - Factoring of XML Schema Artifacts
- From: "Mark Ford" <mark.ford@active-endpoints.com>
- To: <wsbpel@lists.oasis-open.org>
- Date: Sun, 4 Jun 2006 19:45:44 -0400
+1 with respect to having a single definition for property,
propertyAlias, and service-ref
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 - 294 - Factoring of XML Schema Artifacts
Status:
received
Date added: 4 Jun 2006
Date submitted: 02 June
2006
Submitter: Dieter
Koenig
Document: WS-BPEL 2.0 XML Schema
Description:
According to the resolution of issue 24, there will be two WS-BPEL 2.0 XML
schema artifacts, each with its own target namespace, one for Executable
Processes and one for Abstract Processes.
There are several problems associated with this approach:
- The XML schema types and elements for Properties and Property Aliases
appear currently in the Executable Process namespace. It is *unclear* whether
they should also be in the Abstract Process namespace as well. If they are,
then it is *unclear* which one to use in the WSDL.
- The XML schema types and elements for Service References would similarly
appear in both namespaces - it is *unacceptable* that the namespace changes
when switching between Abstract and Executable - if this schema type would
appear on a WSDL operation then this switch would cause a change of the
interface.
- For XPath extension functions defined by WS-BPEL, we again have the same
situation: is is unclear whether both namespaces would be used to qualify them
- again, it is *unacceptable* that the namespace changes when switching
between Abstract and Executable.
- The XML schema contains many global element definitions instead of just
<process> - it is therefore allowed to create valid documents that only
contain a <property> element (or a <copy> element, etc.), which is
useless and not mandated by the WS-BPEL 2.0 specification.
Submitter's proposal: [Just one option - subject to
discussion] Refactor the WS-BPEL 2.0 XML schema artifacts into the following:
- One WS-BPEL 2.0 XML schema for validation of Executable Processes - the
only allowed root element is <executable:process>
- One WS-BPEL 2.0 XML schema for validation of Abstract Processes - the only
allowed root element is <abstract:process>
- One WS-BPEL 2.0 WSDL extension XML schema for validation of Properties and
Property Aliases - same target namespace as (a) - the only allowed root
elements are <bpel:property> and <bpel:propertyAlias>
- One WS-BPEL 2.0 XML schema for Service Reference variable declaration in
Executable or Abstract Processes - same target namespace as (a) - the only
allowed root element is <bpel:service-ref>
Notes:
- The target namespace values for (a) and (b) are valid URLs that point to
the location of the two artifacts, respectively.
- The location of (c) and (d) is provided in a <xsd:documentation>
element contained in (a) and (b).
- The XML schema artifact (c) has an <xsd:include> for the schema (a)
in order to be able to reuse the WS-BPEL extensibility mechanism.
Changes: 4 Jun 2006 - 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 - 294 - [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 - 294 - 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]