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 ****
|