Hi,
I knew that XScript will come up in this discussion thread. :-)
When I said "a potentially non-portable language or language binding",
I should have emphasized more on the binding part. Even if one language
is portable and standardized, it does not mean the embedding of such a
language is portable and standardized. E.g. both Java and SQL are
standardized, it does not mean embedding SQL in Java automatically
standardized. That is why Oracle standardized SQLJ through ANSI
explicitly.
However, if BPEL invokes the services of another language through a
(local) WSDL, then that is another case. The language binding is more
portable in that case.
One of the major reasons that made me
changed from "neutral" to "for" Danny's suggestion is his argument
about we have not reached any form of plateau yet in terms of
<assign> functionality. Currently, assign has "replace" semantics
only, but not "insertBefore", "appendChild" and "remove". If assign has
those 3 operations, then we at least reach the plateau of DOM API in
structure modification sense.
If assign with replace, insert, append, remove functionality did NOT
fulfill the 80/20 rule, then assign with replace only will sure do not
fulfill the 80/20 rule. Why would we settle with a even smaller % of
functionality coverage?? If X% was bad, why (X-Y)% is better???
Once we reach the plateau of DOM-API equivalent in BPEL 1.1 cycle, it
would let us have a better foundation to leverage XUpdate in BPEL 1.X
cycle in future. Because, we would have a better experience on what
users want to do in terms of XML manipulation.
Another data point to consider: Most of XML DB vendors have DOM
modification support today before similar support got standardized in
upcoming XQuery-Update (aka XUpdate) and SQL/XML (aka SQLX) standards.
The future functions in those standards do NOT invalidate in the usage
experience of DOM API today.
Thanks for reading the email again!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
Why do you
assume that the use of a companion language must be non-portable? If
ECMA, for example, defines a standard way to call out to XScript (the
XML enabled version of ECMAScript) from inside of BPEL then clearly the
result is portable and standardized.
Having a XML manipulation feature that can't handle the most common XML
manipulation use case there is, a while with inconsistent intermediate
states, doesn't seem a worthwhile effort.
I think we need to invoke the 80/20 principle. If the XML manipulation
feature won't meet the XML manipulation needs of 80% of the BPEL's out
there (and the current proposal clearly will not) then is it really
worth the effort?
Yaron
Alex Yiu wrote:
Hi all,
I think Yaron's usecase (while+appendChild) is a valid one, which the
atomicity of assign cannot help much in "schema inconsistent state
situation". :-)
However, as I mentioned before, BPEL community needs to recognize and
agree that the 3 operations (e.g. insertBefore and appendChild)
potentially added by issue 11 are NOT aimed to solve ALL XML
manipulation problems. Those 3 operations are aimed at simple XML
manipulation, NOT complicated ones.
I think it is a good idea to make simple XML manipulation possible in
BPEL and leave complicated XML manipulation to other languages. So, we
will NOT run into a slippery slope situation and re-invent wheels for
other emerging standards. (e.g. XUpdate)
IMHO, it is perfectly fine for us to say some usecases of
while+appendChild cannot be performed by the BPEL language itself.
There
may be semantic (e.g. this schema inconsistent state situation) and
performance deficiency to perform those complicated XML manipulation in
BPEL.
One situation that I want to avoid is:
A user just wants to do a simple insert into an existing document.
There
is no standard mechanism that BPEL specifies to do that. That user is
forced to choose a potentially non-portable language or language
binding
to do just this extremely simple operation. Then, BPEL will end up in a
close-to-zero portability situation.
Thanks for reading this email!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
>
>
> Ron Ten-Hove wrote:
>
>> This is why <assign> is atomic. The intermediate states
are never
>> exposed.
>
>
> Even trivial XML manipulation tends to involve some forms of
> computation during the manipulation process. A classic example is
a
> while loop that goes through a document pulling out information
in
> order to create a new document. During the time the while loop is
> iterating it is likely that the new document will be in a schema
> inconsistent state. Assign's atomicity is of no use here since
there
> is no way to shove a while loop into an assign.
>
> More generally, any XML manipulation which is not strictly linear
and
> involves schema inconsistent intermediate states cannot be dealt
with
> in BPEL since assign cannot contain decision or iteration logic.
>
> Therefore if one wants to enable even simple XML manipulation in
BPEL
> one inevitably ends up having to create some kind of transacted
schema
> free zone. I'm suggesting we don't want to go there.
>
>> Is it your assertion that we should create a standard that
MUST be
>> supplemented by an unspecified companion language, in order
to create
>> executable processes?
>>
>
> Not at all. There are many ways to make BPEL work on its own. But
I am
> asserting that BPEL should focus on the areas that it adds value
and
> not re-invent functionality that is widely available in a
standardized
> form.
>
>> -Ron
>>
>
> To unsubscribe from this mailing list (and be removed from the
roster
> of the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
|