Peter,
Thanks! Understood. Hopefully, the new issue description is "friendly"
to Dieter.
Regards,
Alex
Peter Furniss wrote:
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 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
|