Since 294 hasn't been accepted yet, I'm leaving it as one
for the time being (unless asked otherwise).
Peter
Hi, Dieter,
I am a bit confused.
- I thought we would try to cover Action Item #74 by this issue as
well?
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434
- Also, I suggested to declare formally how normative XML Schema Artifacts
are. Before we go into the GED-vs-LED discussion. If the XML Schema is
informal, there is no point to have a GED-vs-LED discussion.
- The first 3 bullets mentioned in the issue description is related to the
namespace usages, while the fourth is about schema design. They are orthogonal
to each other. One decision does not affect the other. We should NOT mix these
group issues together. Implementation may use other non-XML-schema to enforce
the grammar specified by the spec text or XML schema.
Also, it
seems to me that there would be multiple XML Schema document for the same
Exec-BPEL in the submitter's proposal. I thought I was able to at least to
convince Dieter that one schema document for one target namespace is a good
practice: See: http://www.oasis-open.org/archives/wsbpel/200605/msg00146.html Now
I am really confused.
Anyhow, I formally suggest to add some of the
above concerns to this issue description and spilt this issue into two
sub-issues: one for namespace usage; one for XML Schema status and design
pattern.
[Assume the namespace related issue is numbered as
"294.1".] ----------------------------------------------- Subject:
Issue - 294.1 - Clarification namespace usage in Abstract and Executable
Process 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.
Also, we do
not have text to describe how to treat XPath function of other namespaces. See
action item #74 http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/action_item.php?action_item_id=1434 -----------------------------------------------
[Note:
- (1),(2),(3) are exact copies of Dieter's original issue description. Green
text are added for Action #74.
- In general, for (1) to (3), I agree with Dieter's general direction. Use
"bpel" ns, instead of "abstract" ns all the time in these 3 context. And, I
would propose adding text from Action #74 as well.]
----------------------------------------------- Subject:
Issue - 294.2 - Clarification of normative status of XML Schemas and
decisions on preferred design patterns
Description:
- Normative Status:
- Whether the XML Schema provided this specification is normative was
discussed in a conf call few weeks ago. However, there was no formal
conclusion reached during the conf call. A formal clarification/decision
should be reached before discussing other topics regarding to schema and
grammar enforcement by the specification.
- Another question include: do we allow WS-BPEL implementation to
implement other xml grammar language to enforce the syntax of this
specification?
- XML Schema Design Patterns:
- One or multiple schema document: For XML syntax of one
particularly target namespace, should we have one XML schema to cover its
definition? Or, we should have a set of disjoint XML schemas to cover one
namespace?
- GED-vs-LED: In XML Schema, an element can be in forms of either
Local Element Declaration (LED) or Global Element Declaration (GED). Which
pattern are the preferred one? There are different pros and cons in this
decision.
- In BPEL 1.1 main XML schema, there are a number of elements which are
GED: "process", "from" and
"to"
-----------------------------------------------
I
will send a seperate email to submit a proposal for the second subissue.
Thanks!
Regards, Alex Yiu
ws-bpel
issues list editor wrote:
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 ArtifactsStatus:
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
|