+1 to Charlton (having separate NSs)
Hi Danny,
It seems to me that in all likelihood if code
is needed to perform custom validation instead of using some (third-party) Schema-aware
tool, then it should not be challenging to change the ‘custom code’
to handle multiple namespaces.
Actually, I think this is more of an
argument towards having separate NSs. If we keep them in the same NS, people
will have to write more custom validation code instead of being able to
leverage Schema-aware tools, as we will be incurring more Schema inexpressible rules.
Rgds,
From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Wednesday, November 30, 2005
2:47 PM
To: wsbpel tc
Subject: Re: [wsbpel] Issue 82.1 -
proposal to vote (directional vote)
Although I was originally for the separation (After
all I was the one who proposed issue 24), I have mixed feelings now.
(It's been more than 2 years....)
One argument for keeping them in the same namespace is that there are many many
static analyses which are completely syntactic, yet unexpressible in
schema. Any code that is written to perform such validation, if it is
namespace aware, will have to either be copied, or engineered in such a way
that it can deal with the multiple namespaces.
Alex Yiu wrote:
+1 to Charlton.
Regards,
Alex Yiu
Charlton Barreto wrote:
Abstract and Executable BPEL have distinct and different syntaxes. While
there are similarities between the two, they are not the same.
I agree that the important issues are usability and schema design and
maintenance. For these reasons, we should not force Abstract and Executable
BPEL into a single namespace. Doing so would only complicate and confuse
usage, while making the schema design and maintenance problematic.
On the other hand, assigning each its own namespace will only serve to
maintain clarity in use and description, and make it easier to keep them
distinct from one another, simplifying schema design and maintenance.
-Charlton.
On 30.11.05 13:31, "Francisco Curbera" <curbera@us.ibm.com> wrote:
How "different" abstract and executable are is probably a matter of
subjective perception. I happen to think that with the resolution of issue
82 we have made it clear abstract semantics are based on executable
semantics so they cannot be that different. The real important issues are
the usability of the resulting language(s) and XML Schema design and
maintenance.
Paco
Alex Yiu
<alex.yiu@oracle. To: Rania Khalaf
<rkhalaf@watson.ibm.com>
com> cc: Charlton Barreto
<cbarreto@adobe.com>, Ron Ten-Hove
<Ronald.Ten-Hove@Sun.COM>,
wsbpeltc <wsbpel@lists.oasis-open.org>, Alex Yiu
11/30/2005 11:52 <alex.yiu@oracle.com>
AM Subject: Re: [wsbpel] Issue
82.1 - proposal to vote (directional vote)
Rania,
Maybe I could refine what charlton said a little bit ... I would say:
Abstract and Executable Process are two very different and distinct
aspects of BPEL specification. That is why we need to spell out their
differences at the very beginning of Introduction section.
Also, their syntax rules are totally different. Please recall that: XML
and XMLNS usage of source code language in BPEL spec are mainly for
syntax validation.
One more important point to add: Different XMLNSes do not imply that XML
constructs of different XMLNSes are two disjoint language. Currently,
<partnerLinkType> and <propertyAlias> are under another NS, not the main
BPEL source code NS. They are definitely considered as an integrated
part of BPEL specification and language.
Thanks!
Regards,
Alex Yiu
Rania Khalaf wrote:
Hi Charlton,
This is exactly the misconception I was hoping to avoid.
I refer to the 'two distinct languages' note below. One is simply a
partial view on the other, with the common parts having the same
semantics.
Charlton Barreto wrote:
+1 to Alex and Ron. Abstract and Executable BPEL represent two
distinct languages, each with its own syntax. Each ought to be
described by its own schema, and thus belong to its own namespace.
------------------------------------------------------------------------
*From:* Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
*Sent:* Tuesday, November 29, 2005 1:44 PM
*To:* Rania Khalaf
*Cc:* 'wsbpeltc'
*Subject:* Re: [wsbpel] Issue 82.1 - proposal to vote (directional vote)
Rania,
I have to disagree about using a single name space. Although the
abstract and execution languages are similar, they are *not *the
same. Forcing them into the same name space will be confusing, and
make existing schema-aware tools less useful, since will have to
depend on semantics where simple syntax could have sufficed.
We shouldn't dismiss dual schemata as as impractical. There are
several approaches to this that avoid the horrors of
cut-and-paste.Other TCs have tackled similar problems; I'm sure this
TC can as well.
-Ron
Rania Khalaf wrote:
Hi Alex,
I think going with the second point, that it doesn't make much sense
to split the namespaces. Especially, as Yuzo had mentioned, that
most tools don't support advanced XSD features and as Danny also
said if there's no really compelling reason to manage several XSDs
and changes we should try to keep it simple.
As for cut and paste, the ns decl is up top anyway, so in many cases
a cut and paste is just that and people will be able to copy bits
with opaque in them.
my .02.
rania
Alex Yiu wrote:
Hi all,
I think we should still have distinct namespaces between Abstract
and Executable BPEL, after most of 82.* got resolved. Major reasons
are:
* There are _significant amount of syntax differences_ between an
Abstract Process with _opacityOmissionUsed="yes"_ and Exec
Process. (I am talking about the Abstract base, not AP11
profile;
essentially all compulsory element and attributes becomes
optional.).
* On the other hand, there are _moderate amount of syntax
differences_ between an between an Abstract Process with
_opacityOmissionUsed="no"_ and Exec Process. (I already capture
those differences in my previous email).
* I am worrying people uses _copy-and-paste and mix-and-match
between Abstract and Executable BPEL_. (e.g. copying a
fragment of
empty <scope> from an Abstract BPEL into Exec BPEL). If we
use the
same namespace for both kinds of BPEL, it would be difficult for
us to tell that users are doing this kind of mistakes. If we use
different namespace, if people use an XML-aware tool to do
such a
copy-and-paste, we can detect that kind of mistakes more easily.
* With both AP11 and Template profiles, I tend to forseee people
would create the Executable Process based on Abstract Process
with
sometool help, given with constraints specified in the profile.
Even when people want to create an Executable BPEL based on
Abstract BPEL with just emacs/notepad. People just need to
following:
1. copy the BPEL file
2. _make one-line of change_: changing XMLNS declaration from
Abstract to Exec BPEL.
3. add extra BPEL constructs for Execution Completion.
Having two distinct namespace will allow us to
_validate the
Exec BPEL code during step (3) by using XSD_. Hence,
having
multiple NS gives us more tool to do BPEL validation,
while
collapsing Abstract and Executable do not yield any user
benefits.
Thanks!
Regards,
Alex Yiu
Peter Furniss wrote:
I thought we said (or maybe it was just me) that we should revisit 24
once we had sorted out (in 82.*) just how much difference there was
between syntax e and syntax a. When issue 24 was resolved we were
anticipating a quite different scale of differences. I had to
drop out
of active involvement in 82 soon after that, I do think we should
consider rescinding 24 (sorry Diane)
Peter
-----Original Message-----
From: Rania Khalaf [mailto:rkhalaf@watson.ibm.com] Sent: 22
November 2005 16:28
To: Alex Yiu
Cc: wsbpeltc; Rania Khalaf; Danny van der Rijn; Ron Ten-Hove;
'Monica J. Martin'
Subject: Re: [wsbpel] Issue 82.1 - proposal to vote (directional
vote)
Hi guys,
If we agree about the schema of abstract will only add the opaque
tokens then I don't see any motivation any more for 24's
resolution .
Is it really worth all the pain of xsd:redefine and managing
three schemas instead of just saying in the text that you can
only use abstract tokens in AP ?
regards,
Rania
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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