|
Hi all,
I've attached Alex's recap below - minutes from the
June 17th meeting w/b forthcoming. We made good progress, but all agreed to meet
again in a little more than a week to give people time to peruse the
existing proposals and discuss offline, so that we can drive toward some sort of
resolution. As such I wish to table Issue 157 at this Wednesday's
conference call (June 22, 2005).
Our meeting will be at 0800 PDT/1100 EDT/1600 GMT/1700
CET on Tuesday, June 28th. If you are interested to join and were not on last
weeks conf call, please let me know.
Cheers,
-Charlton.
Adobe
Systems, Inc.
Hi all,
A partial brief recap on Issue 157 Conf
Call:
I think the conf call today (moderated by Charlton) went
quite well today, especially the second half. (Thanks Charlton for organizing
this conf call and moderating it)
There are two replacement tables that
have been sent out so far:
(1) The table that I sent out during F2F on Jun
02:
http://lists.oasis-open.org/archives/wsbpel/200506/msg00013.html
[
plus a potential amendment to simplify the picture Attr/Text-to-Elem copy with
adding "substituteElementName" to Elem-to-Elem copy:
http://lists.oasis-open.org/archives/wsbpel/200506/msg00109.html
This table hereinafter is known as "F2F-Table".
]
(2) The table that Rania sent out yesterday /
today
I think most of us on the conf call agree the
relation of the two tables can be described as follows:
- Rania took a subset of "F2F-Table" and spilting some rows and columns:
spilting element into element-node and element-value and attribute into
attribute-node and attribute-value
- Some people may perceive "node" is related to <xsl:copy-of> and
"value" is related to <xsl:value-of>. After some discussion, we agree
that is not actually case. The "node-vs-value" distinction is actually not
perfectly in sync with those two definition.
- Under one of my suggested interpretation, the entries in "F2F-Table" can
be actually mapped to entries for value-to-value in Rania's replacment table.
Hence, Rania's table can be considered an expansion of "F2F-Table"
potentially. We may NOT have any fundamental conflicts between these two
tables.
Steps to carry out this discussion forward:
- Clarify what "node-vs-value" exactly means in Rania table. (One of my
suggested intepretation will be re-iterated below)
- Decide whether the benefits of entries of "node-to-node" copy worths the
complexity for us to define it. Hence decide which to keep which
"node-to-node" copy.
- Build a formal consenus on a well-defined replacment table based on
"F2F-Table" and Rania's table as the input (e.g. how we handle XSD's
SubsitutionGroup pattern)
- Find out whether it is feasible to use XSLT to define / describe those
entries of replacment operation in the table. If feasible, we need to decide
the scope of XSLT definition as well (e.g. how formal and how universal the
XSLT definition can be applied) and produce the actual XSLT fragments for such
definitions / descriptions. (See below my current gut feelings about
how formal and how universal the XSLT definition can
be)
Node-vs-Value Distinction: [ Based on intepretation
of type (simpleType / complexType) and Content (simpleContent / complexContent)
design from XSD ] [ using informal terms for ease of understanding for now
]
Element:
- Value(s) of an Element : its attributes and its child content nodes (not
including the element name)
- The element name is the "head" of element-node, while the value(s) of an
element is the "body" of the element-node.
Attribute:
- Value of an attribute: its definition is trivial
- The attribute name is the "head" of attribute-node, while the value of an
attribute is the "body" of the attribute-node.
"F2F-Table"
focuses on value-replacement logic (not node-replacement): modelling assignment
statement in a typical procedural language and maintaining "assign-then-copy"
post-condition.
Thanks!
Regards,
Alex
Yiu
Alex Yiu wrote:
Hi Rania,
Charlton and all others,
Thank you for sending those individual files
to me.
Yes, Oracle email server does not accept zip file attachement
unfortunately.
If you guys want to send a zip file to an Oracle address in
future, please send with an alternative file extension. E.g.
"foo.zip.rename" ... :-)
[A]
I want to remind people that we
have sent out a draft during F2F.
http://lists.oasis-open.org/archives/wsbpel/200506/msg00013.html
Actually,
we have NEVER held a formal discussion over the design choices listed
in the above email.
I would like to suggest to put the
replacement-table in the above email in tomorrow conf call agenda.
Rania and Charlton, I would hope you guys can spend some time
reading that table up.
[B]
At the same time, I would to
remind how <bpel:copy> is defined in BPEL 1.1 and what we have discussed
on Issue 157 so far in Palo Alto F2F.
BPEL 1.1 has already given some
high-level design guidlines of <bpel:copy>. Unfortunately, some of
detailed definition is not present in BPEL 1.1. The goal of Issue 157 is to
flesh out and clarify those details.
BPEL 1.1 defines the
following so far:
- BPEL (including <bpel:copy>) should be expression language
independent generally speaking.
- The from-spec and to-spec of <bpel:copy> should yield exactly one
node. Otherwise, selectionFailure will be triggered.
- mismatchedAssignmentFailure will be thrown, when incompatible
types are encountered in an assign activity.
In the last
F2F, if my memory serves me right, we have voted and agreed on the
following:
- "Copy Should Really be a Copy followed by a Replace"
- "Copy Should Only Deal with EIIs, AIIs and TIIs"
- "Copy Should Not be Schema Aware" at runtime, because XPath 1.0 is our
default language and its data model is not schema aware. Vendors are allowed
to do static analysis on <copy> based on schema. If a vendor choose to
use a data model which is schema aware, copy can be schema aware at runtime
Based on BPEL 1.1, I would like to lay down more major design
principles to guide us to define the behavior for the replace-logic
(similar to what we did in the F2F):
- <bpel:assign><bpel:copy> operations SHOULD be modeled
after assign statement in typical procedural language.
E.g.:
<assign> <copy>
<from>
$var/foo/bar[2] </from>
<to>
$var2/foo2/bar </to>
</copy>
</assign>
The effect of the above assign should be
similar to assignment in C++:
var.foo.bar[2] =
var2.foo2.bar;
A more real life example that
we need to support would be:
<assign>
<copy>
<from>
$poVar/billingAddr </from>
<to>
$poVar2/shippingAddr </to>
</copy>
</assign>
(Think of the above as: poVar.billingAddress
= poVar2.shippingAddr; )
- The "assign-then-equal" principle: The post condition of
<bpel:assign> and <bpel:copy> would be the from-expression would
be equal to to-expression. E.g.:
var.foo.bar[2] =
var2.foo2.bar;
will
make
(var.foo.bar[2] == var2.foo2.bar) becomes true
Note: what "equal" means varies from one expression language to
another expression language. Since we adopt XPath 1.0 as our default
langauge, we should try our best to ensure majority cases (not
necessarily all cases) that after execution of :
<assign>
<copy>
<from>
from-expr </from>
<to> to-expr </to>
</copy>
</assign>
(from-expr = to-expr) evaluates to true
in XPath 1.0
Note: there is more than one equal operators in XPath
2.0 to supplement the deficiency in XPath 1.0
- The design of <bpel:copy> should make type analysis
easy: Even though we cannot enforce schema-aware at runtime due to
adopting XPath 1.0 as our default language, the design of <bpel:copy>
should facilitates static analysis schema types. Similarly, if we adopt
XPath 2.0 in future, our current design <bpel:copy> should NOT make
runtime mismatchedAssignmentFailure fault detection difficult.
[C]
I will go through your XSLT samples and document
attachement in details today. By browsing it quickly, my first responses are:
- High level speaking, I agree with your approach. Splitting the design
into two parts: (1) define a replace-semantic table / matrix (this part is
outside of XSLT) (2) then to define the entries in table and try to
see whether it is feasible and economical to use XSLT in those
definition of those entries. Coincidentally, that would be my
preferred high level approach also. :-)
- For part (1): the table part, quickie comments:
- Could you clarify the distinction in your mind of "node" vs "value"?
By going through your examples, I think I can induce by examples what you
meant. Can you bind these two concepts to a formal data model? DOM? XPath
DM? Anyway, if my induction is correct, your distinction of
"node-vs-value" may mismatch XML Schema model. IMHO, the "node" concept
should be mapped element/attribute declaration, while "value" concept
would be mapped to XSD type definition.
E.g. element-name is the
"head" of the "node", while the attributes and all children are the
"values" of the "node".
- The table in Rania's doc can be related to the table sent out during
F2F in the following way: picking the 2x2 square for EII and AII matrix
and expand it with by adding element-node and attribute-node columns. The
F2F table focus on the value copies and replacement, not the nodes copies
and replacments (note: I am using my schema-oriented definition of
node-vs-values).
IMHO, I am not sure we want to expand
<bpel:copy> to do a bunch of node-copy as Rania has illustrated. I
am not sure there is a great need for that. (e.g. En-Ev, An-En,
An-An). And, we have enough entries in the F2F table for us to build
consensus on already. Also some of those operations are not in sync with
the principles that I lay out above.
Example: The
assign-then-equal principle cannot hold for An-to-An operation.
Example: From "$poVar/billingAddr" to "$poVar/shippingAddr" does
not seem supported (in EN-to-EN or EV-to-EV operations).
- It seems to me that Rania's table does not address copying to
simple-type variable situation. That's a relatively minor issue.
- For part (2), your XSLT to define entries in the table:
- Actually, you don't need to mention anything like:
select="document('&fromDocument;')&fromNodePath;"
Because
the from-spec can be more complicated that just a simple expression like
<from> $var1/some/xpath/here </from>. I guess we can represent
a from-spec as a parameter. e.g.:
select="$theNodeReturnedFromSpec"
- The flip side of the coin: A to-spec can be non-trivial and refer to
multiple variables as well. e.g. <to> ($var1 |
$var2)//lineItem[@product='33'] </to>
Given that to-spec, if
we use XSLT to describe <bpel:copy> behavior, we may need to
generate two result trees. one for var1 and one for var2. However, only
XSLT 2.0 can generate multiple result trees, while XSLT 1.0 cannot.
[ As of this moment, I am still having doubts on
the feasible and economical aspect of using XSLT as a formal definition
language to define all entries in replace table for <bpel:copy>. ]
Thanks!
Regards,
Alex Yiu
Rania
Khalaf wrote:
Retrying since you don't accept .zip. Please copy all into same dir.
Thanks,
Rania
(See attached file: tev.xsl)(See attached file: 157table.doc)(See attached
file: anan.xsl)(See attached file: anen.xsl)(See attached file: avav.xsl)
(See attached file: avev.xsl)(See attached file: enen.xsl)(See attached
file: enev.xsl)
(See attached file: evav.xsl)(See attached file: evev.xsl)(See attached
file: tav.xsl)
----- Forwarded by Rania Khalaf/Watson/IBM on 06/16/2005 12:58 PM -----
|---------+---------------------------->
| | Rania Khalaf |
| | |
| | 06/16/2005 12:34 |
| | PM |
| | Please respond to|
| | rkhalaf |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Alex Yiu <alex.yiu@oracle.com> |
| cc: Alex Yiu <alex.yiu@oracle.com>, Charlton Barreto <cbarreto@adobe.com>, chris.keller@active-endpoints.com, |
| "'Dieter Koenig1'" <dieterkoenig@de.ibm.com>, Francisco Curbera/Watson/IBM@IBMUS, frank.ryan@active-endpoints.com, |
| Maciej Szefler <mbs@fivesight.com>, Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>, wsbpeltc <wsbpel@lists.oasis-open.org>, |
| "Yaron Y. Goland" <ygoland@bea.com> |
| From: Rania Khalaf/Watson/IBM@IBMUS |
| Subject: Re: [wsbpel] Issue - 157 - back to main list |
| Importance: Urgent |
| Importance: Normal |
| |
| |
>------------------------------------------------------------------------------------------------------------------------------|
Hi guiys,
I have been looking at this and the more I do so the more I think that
there is a compromise approach that solves all our problems:
-Does copy as it is today without extending capabilities. How: focus only
on what copy can do today and don't add additional features
-Uses XSLT to define precise semantics but does not require XSLT support or
introduce XSLT to the BPEL process.
How: define XSLT scripts that perform the copy stated in the cells in
the copy-table, and state that the target of that particular copy must, at
the end of the copy, have the same XML as the output of having run that
particular script. The scripts we define are a small finite set and we do
not open random XSLT-ing to the public. Hence, this is copy by
"XSLT-analogy" ;)
-Distinguishes properly to the process designer what the intent of the copy
is, without having to do guess work. How: reuse the idea of value-of vs.
copy-of to determine whether the designer is trying to copy from/to a
whole node or just the text value child.
I am attaching an explanation. I think this is easy, simple, unambiguous,
does not mangle XSLT, and takes the guess work out of the rest of it.
I would like to use this as one of the inputs to tomorrow's call so would
need to circulate to TC this pm or tomorrow am. Comments welcome.
Regards,
Rania
**** Attachment 157.zip has been removed from this note on June 16, 2005 by
Rania Khalaf ****
|