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