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 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
|