Let me add more point for clarification.
There is a fifth XSD artifact for partnerLink type definition. That is
left untouched.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi All,
I have exchanged some notes with Dieter. I am OK with picking [B] as
well. Given that, here is the revised
proposal, which Dieter considers a friendly amendment.
===========================
We would have 4 XSD artifacts which can be used by public:
(1) One XML schema for validation of WS-BPEL 2.0 Executable Processes
(2) One XML schema for validation of WS-BPEL 2.0 Abstract Processes
common base
(3) One XML Schema for "property" and "propertyAlias".
(4) One XML Schema for "service-ref"
Note:
- If some XSD definition and declaration can be used between in
(1)
and (2), it will be factored into a "core" XSD file.
- (2) is defined for the A.P. common base. There may be
additional
XSD for
different abstract process profiles.
- All 4 XSD has its own target namespaces, which are potentially
derefereneable. Details of the namespace is TBD. We will confirm it by
holding a simple vote for Issue 289.
- We are leaving out "GED-vs-LED" issue out of resolution text.
===========================
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Definitely a friendly amendment - thanks!
Kind Regards
DK
Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com> To
Dieter Koenig1/Germany/IBM@IBMDE
29.06.2006 04:07 cc
Alex Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 294.1 -
Proposal for Vote
Hi Dieter,
I am OK with picking [B] as well. Given that, here is a revised proposal.
Hopefully, you would consider a friendly amendment. If so, we can send the
following out as the proposal to the public email list:
===========================
We would have 4 XSD artifacts which can be used by public:
(1) One XML schema for validation of WS-BPEL 2.0 Executable Processes
(2) One XML schema for validation of WS-BPEL 2.0 Abstract Processes common
base
(3) One XML Schema for "property" and "propertyAlias".
(4) One XML Schema for "service-ref"
Note:
If some XSD definition and declaration can be used between in (1) and
(2), it will be factored into a "core" XSD file.
(2) is defined for the A.P. common base. There may be additional XSD
for different abstract process profiles.
All 4 XSD has its own target namespaces, which are potentially
derefereneable. Details of the namespace is TBD. We will confirm it
by holding a simple vote for Issue 289.
We are leaving out "GED-vs-LED" issue out of resolution text.
===========================
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
My preference is [B]:
- WSDL extensions are separated from the WS-BPEL language
- The service-ref element is not part of any language
(compatibility considerations do not apply as the namespace changes
anyway
in WS-BPEL 2.0).
Kind Regards
DK
Dieter König Mail:
dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49)
7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49)
7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49)
7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com>
To
Dieter
Koenig1/Germany/IBM@IBMDE
28.06.2006 00:05
cc
wsbpel@lists.oasis-open.org,
Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 294.1 -
Proposal for Vote
Hi Dieter,
Thanks for being flexible on this "GED-vs-LED" issue.
Even though I still think that GED design pattern is very much
preferred
over LED and GED will be used as much as possible similar to the
Schema for
WSDL 2.0 and Normative Schema for XML Schema 1.0, ... I totally
agree with
you that that we should take this "GED-vs-LED" issue out of
resolution text
.
Given that I would suggest some further clarification/amendments to
the
proposal:
For (1) and (2):
-----------------------------
(1) One WS-BPEL 2.0 XML schema for validation of Executable Processes
(2) One WS-BPEL 2.0 XML schema for validation of Abstract Processes
Base
Note:
If some XSD definition and declaration can be used between in
(1) and
(2), it will be factored into a "core" XSD file.
(2) is defined for the A.P. Base. There may be additional XSD
for
profiles.
-----------------------------
Then, the next point that that I would like to mention is: IMHO, we
should
maintain a relation between one target namespace, one XML Schema (or
one
set of XML Schema files connected by <xsd:include>). Because, the way
that
we did it in BPEL 1.1 is a bad practice of schema and I have not seen
similar patterns in the other specs. As I mentioned, BPEL 1.1 way to
split
one namespace into multiple *disconnected* schema documents, similar
to
having one package of Java classes archived into multiple jar files.
If people agree with that I say so far, there are two ways for us to
maintain this cleaner relationship between namespace and schema.
Decision points: whether we want to keep "property", "propertyAlias",
"service-ref" in the same namespace of the Exec BPEL.
If yes, [A] I would suggest to declare those 3 elements into XSD of
(1) as
well.
If no, [B] I would suggest:
To have one namespace in "property" and "propertyAlias", e.g.
".../wsbpel/property.xsd"
To have one namespace in "property" and "propertyAlias", e.g.
".../wsbpel/service-ref"
Then, we have two more XSD files.
I don't have a strong preference between [A] and [B]. They are both
OK to
me as long as we don't need to spilt the XSD of the same namespace
into
multiple disconnected pieces.
Further thoughts?
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Alex, minimizing the number of GEDs is preferable, however, we
believe that
it is more important to get to a resolution at this point in
time.
Kind Regards
DK
Dieter König Mail:
dieterkoenig@de.ibm.com IBM Deutschland Entwicklung
GmbH
Senior Technical Staff Member Tel (office):
(+49)
7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office):
(+49)
7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office):
(+49)
7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com>
To
Dieter
Koenig1/Germany/IBM@IBMDE
26.06.2006 21:39
cc
wsbpel@lists.oasis-open.org,
Alex
Yiu
<alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue -
294.1 -
Proposal for Vote
Question:
Your proposal does not mention the GED-vs-LED decision issue.
Did you
make
it silent intentionally? Or, your team may still have a
preference?
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Hi Alex, can you elaborate which part is not clear from
your
point of
view?
Kind Regards
DK
Dieter König Mail:
dieterkoenig@de.ibm.com IBM Deutschland
Entwicklung
GmbH
Senior Technical Staff Member Tel
(office):
(+49)
7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax
(office):
(+49)
7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home
office):
(+49)
7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com>
To
Dieter
Koenig1/Germany/IBM@IBMDE
23.06.2006 21:52
cc
wsbpel@lists.oasis-open.org,
Alex
Yiu
<alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue
-
294.1 -
Proposal for Vote
Hi Dieter and others,
Part of this proposal is not that clear about its intent.
Upon receiving clarification, I may need to make some
amendment
or
submit a brand new proposal.
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Based on the issue 294.2 resolution proposal, we
propose
that
the WS-BPEL
XML Schema artifacts are restructured as follows:
Submitter's proposal:
Refactor the WS-BPEL 2.0 XML schema artifacts into
the
following:
(a) One WS-BPEL 2.0 XML schema for validation of
Executable
Processes
(b) One WS-BPEL 2.0 XML schema for validation of
Abstract
Processes
(c) One WS-BPEL 2.0 WSDL extension XML schema for
validation of
Properties
and Property Aliases - same target namespace as (a)
(d) One WS-BPEL 2.0 XML schema for Service
Reference
variable
declarations
in Executable or Abstract Processes - same target
namespace as
(a)
Note: the target namespace values for (a) and (b)
are
valid
URLs that can
point to the location of the two artifacts,
respectively.
Kind Regards
DK
Dieter König Mail:
dieterkoenig@de.ibm.com
IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel
(office):
(+49)
7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax
(office):
(+49)
7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel
(home
office):
(+49)
7032-201464 Germany
---------------------------------------------------------------------
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
|