Attached are two documents which represent Alex's
proposal on Issue 157, reflecting the work the small group has performed over
the last few weeks to converge on it.
-
The WS-BPEL_Issue_157_Proposal.doc represents the
"Formatted Proposal", which is how we intend to implement the changes to the
specification.
-
The
WS-BPEL_Issue_157_Proposal_with_changelog.doc represents the
change-logged proposal, which includes all the latest concurred input
(including that from Monica, Ron, Yaron and myself) to Alex's Proposal Draft
from 2005-July-29, this doc being in sync with the "Formatted Proposal".
The difference between the two is that the "Formatted
Proposal" reorganises the relevant sections so as to follow the layout of the
spec, while the change-logged proposal represents all the changes with editorial
notes to indicate the organisation and ordering. At present I have the pen
on these, so please don't hestitate to contact Alex or myself if you
have any questions.
Cheers,
-Charlton.
Adobe
Systems, Inc.
Hi Yaron,
Thanks for your detailed feedback!
[
Note: Charlton and I are consolidating feedbacks from people (including Monica
and Ron) as of this moment, we would send out a updated proposal soon.
]
See comments inline ...
Yaron Y. Goland wrote:
The requirement that
two WSDL message types be the same seems too restrictive given our removal of
automatic schema validation. If I have two WSDL message types which are
identical in all but name then I should be able to copy between them. I
suspect we should remove all restrictions regarding WSDL message type
requirements and instead allow people to use validation to detect if
incompatible types have been copied.
[A] The
first two bullets are clarified to just talk about
message-variable-to-message-variable copy. A message part to message part is now
clearly excluded. E.g.: Copying a message var of "foo:msgType1"
which has an element message part called "payload" to a message var of
"bar:msgTypeX" which has RPC parts "arg1" and "arg2" is not allowed
by this spec text. Do you really mean to allow it happen?
On the other
hand, copy from the "payload" part of msg var of "foo:msgType1" to "arg2" part
of msg var of "foo:msgTypeX" is clearly allowed here.
"In all other cases,
if the selection results of from-spec (i.e. source) and to-spec (i.e.
destination) are XML Infoset Items or data items in an XML data model, and the
XML Schema types of those selections are known, then the source value MUST
possess the type associated with the destination."
The MUST in the
previous sentence should be a SHOULD since even if the schema type is known it
isn't always clear if it's possible to do static validation. Also note that
the language leaves a huge back door since, for example, XQUERY doesn't use
XML Schema and so none of the language in the paragraph would apply.
[B] The "MUST" is already under the condition
is already under the condition of "if ... XML Schema types of those
selections are known". Is that good enough?
What do you mean by
XQuery does not make use of XML Schema? http://www.w3.org/TR/xpath-datamodel/ http://www.w3.org/TR/xpath-datamodel/type-hierarchy.png
After
XML validation and before any modification, the types of an XML data can be
known in XQuery data model.
"However, since XPath
1.0 data model is not schema aware, no XML Schema type checking is performed
at <copy> operation during runtime, when the default XPath 1.0
expression/query language binding is used."
I think this sentence
should be followed by a very clear statement just pointing out, once again,
that schema validation is not guaranteed and give some examples (like mixed
languages, e.g. a different language for source and destination only one of
which is schema aware) of where schema validation might not be available.
[C] Your input is very welcome here. Can you
draft a paragraph for us to put it into the proposal?
"Text Information
Item (TII) is a sequence of zero or more CII according to the document order.
When it is mapped to XPath 1.0 model, it is a generalization of String-Value
(which has zero or more characters) and Text Node (which has one or more
characters). RValue of a TII can be mapped to a String-Value or a Text Node in
XPath 1.0, while LValue of a TII can be only mapped to a Text node. "
This definition is incomplete since the infoset doesn't contain a way
to point at something that isn't there. So how exactly do you define a
character that isn't there? One way around this problem would be to actually
define the TII as a full fledged infoset item whose attribute points at a
series of CharIIs. Then specify that it is legal to have a TII which points to
no CharIIs and that is therefore an 'empty' TII. But this only makes sense for
the RValue.
[D] Actually, I think we are just
using different words to say the same thing. The current proposal says: TII is
"a sequence of zero or more CII". You said TII has an "attribute points at a
series of CharIIs". If you think adding the word attribute here are better. I
have no problem to add that. How about?
"Text Information Item (TII) is
an Information Item of which an attribute points to a sequence of zero or more
Character Information Item."
Where I get confused
is in the case of an LValue. I suspect we would be wise to just ban empty TIIs
as LValues. Otherwise we end up with some mind bending problems that even
XPATH can't handle. For example, <foo><bar/></foo>. Imagine
I want to point to the 'empty' space before <bar/> and copy something
there. XPATH can return an empty string but that empty string doesn't point to
anything so there is no way to resolve the LValue.
I think it's
cleaner to just say that we don't support that kind of fine grained copy.
[E] We do have have a clear distinction
between R-Value and L-Value here. Quoted from the updated version of the
proposal: ------------------------------- An RValue of a TII MAY
be mapped to a Text node, a String/Boolean/Number object, or [normalized value]
property of an AII in XPath 1.0, while an LValue of a TII MUST be mapped to a
Text node or [normalized value] property of an
AII. -------------------------------
That means, the LValue
cannot be empty (excluding attribute value case), since Text node cannot be
empty.
Given the above example and current proposal text,
We do
ban the following 2 <copy> operations already:
--------------------------- <assign>
<copy> <from> '123'
</from>
<to>$fooVar/bar/text()</to>
</copy> </assign> --------------------------- --------------------------- <assign>
<copy> <from> '123'
</from>
<to>$fooVar/text()</to>
</copy> </assign> --------------------------- As the above
to-spec returns zero nodes (also a text node cannot be empty), a
selectionFailure would be thrown.
We do allow the following copy
operation:
--------------------------- <assign>
<copy> <from> '123'
</from>
<to>$fooVar/bar</to>
</copy> </assign> --------------------------- The to-spec
returns an Element node and the RC logic kicks in.
If the
data-before-copy becomes: <foo><bar attr1="" /></foo> We do
allow the following copy operation:
--------------------------- <assign>
<copy> <from> '123'
</from>
<to>$fooVar/bar/@attr1</to>
</copy> </assign> --------------------------- The to-spec
returns an Attribute node and the RC logic kicks in.
"All existing message
parts in the destination WSDL message variable (referred by the to-spec) will
be removed and all existing message parts in the source WSDL message variable
(referred by the from-spec) will be copied and added to destination WSDL
message variable."
This language worries me because it makes implicit
promises about preserving any data that may be associated with the WSDL
'wrapper' (whatever that is). I suspect it might be cleaner to specify that
the source WSDL message variable will be copied and that copy will become the
value for the destination. This implies that everything at the destination is
wiped out. Of course six of one, 1/2 dozen of another.
[F] Forgive my ignorance. What is a "WSDL
wrapper"? I guess that is another "elephant" thingy. ;-) ... We are just talking
message parts here in the paragraph of the proposal. Any implication to "extra
data assocated with 'WSDL wrapper" is purely reader's extrapolation (or even
imagination), which is outside the scope of the spec.
If you think you
are just trying to suggest an alternative paragraph but to define the same
semantics (as you put it, "six of one, 1/2 dozen of another"), please feel free
to suggest a variant version.
"(That is,
"selectionFailure" checking from BPEL 1.1 is retained.)"
I'd remove
the 1.1 reference as it is likely to cause confusion rather than clarity.
After all, exactly how did 1.1 define selectionFailure semantics? It's a
question we are better off not trying to answer.
[G] I totally agree with you here. :-) That
is an overlook. I forgot to remove that sentence in the formal proposal.
"After the node is
yielded from the source, the "string()" function will be applied to the node
to obtain its string-value as the source content, if the default XPath 1.0
binding is used in the from-spec. If the other expression language is used, a
function other than "string()" may be applied to the node to obtain the source
content"
I think this should be defined in terms of Infoset by
specifying a string of CharIIs in doc order. We can then put in a note saying
that in the case of XPATH 1.0 this maps to the string() function. Although I'm
sure there will exist some subtle difference that will make our lives hell but
such is life.
[H] I tend to agree with you
here. The doc order part is a part of TII definition, I will just reuse that
defintion here. How about the following new text? --------------------------------------------- After the Information
Item is yielded from the source, a TII will be computed based on the source
Information Item as the source content. The "string()" function
MUST be applied to the source Information Item to obtain its
string-value as the source content, if the default XPath 1.0 binding is used in
the from-spec. If another expression language is used, a
function other than XPath "string()" MAY be applied to the node to obtain the
source
content ---------------------------------------------
"Handling Non-Infoset
Data Item in <copy>"
The whole slant of this section is a bit
disturbing to me. These are not non-infoset items, they are just TIIs. I don't
see why it's necessary to refer to them as non-infoset items? There is nothing
an infoset which requires that infoset items necessarily be in a tree,
fragments are fine.
[I] The purpose of that
paragraph is to tell people those data objects (e.g. number) are treated like
TII during <copy> (similar to what you said). But, they are not exactly
TII in other contexts. E.g.:
--------------------- <assign>
<copy>
<from><literal>1.2300</literal><from>
<to
variable="myFloatVar1" /> </copy>
<copy>
<from><literal>1.23</literal><from>
<to
variable="myFloatVar2" />
</copy> </assign> ---------------------
--------------------- $myFloatVar1
= $myFloatVar2 --------------------- should be true, as they are number
objects. If they are 100% identical to TII, then the above evaluation will
become false.
"XML Namespace
Preservation"
A warning needs to go at the end of this section to
explicitly state that if non-XML Schema aware languages (e.g. XPATH 1.0) are
used then it is possible for QNAME values to become invalid due to prefix
conflicts. This really needs to be pointed out with an example. It isn't
obvious and it is important.
[J] Personally, I am
open to that addition of this kind of warning paragraph. Again, could you draft
that paragraph?
Thanks!
Regards, Alex
Yiu
Yaron
Alex Yiu wrote:
Hi all,
This is the proposal draft
for Issue 157. I will try to move it to a formal proposal within a
couple of business days.
Thanks!
Regards, Alex Yiu
------------------------------------------------------------------------
Issue 157 - Proposal Draft
Last modified: July 29, 2005 - 1 pm PDT
(A) Clean up section "Type
Compatibility in Assignment" (formally
numbered as 9.3.1)
Note:
* This cleanup
will resolve Issue 51 as well. (
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue51
) * Yaron suggested that we may want to find a
standardized way to turn off schema-type
static anslysis. That will be a part of Issue
9 discussion.
( http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue9
)
Details of Changes: Under section "Type
Compatibility in Assignment" (formally numbered as 9.3.1):
Change
the section title from: "Type Compatibility in Assignment" to
"Type Compatibility in Copy Operations"
Refine the first paragraph
and first two bullets as follows (the inserted texts are highlighted by
underlines) -------------------------- For a copy operation to be
valid, the data referred to by the from and to specifications MUST be of
compatible types. The following points make this precise:
* The selection result of from-spec is a variable
of a WSDL message type and the
selection result of to-spec is a variable of a WSDL
message type. In this case both variables
MUST be of the same message type, where
two message types are said to be equal if
their qualified names are the same. * The selection
result of from-spec is a variable of a WSDL message
type and the selection result of to-spec
is not, or vice versa. This is not legal
because parts of variables, selections of
variable parts, or endpoint references cannot be assigned to/from
variables of WSDL message types directly.
--------------------------
Change the third bullet and
last paragraph FROM: ----------------------------------
* In all other cases, the types of the source and
destination are XML Schema types or
elements, and the constraint is that the
source value MUST possess the element or type associated with the
destination. Note that this does not
require the types associated with the
source and destination to be the same. In particular, the
source type MAY be a subtype of the
destination type. In the case of
variables defined by reference to an element, moreover, both
the source and the target MUST be the
same element.
The semantics of a process in which any of the
matching constraints above is violated is undefined.
---------------------------------- TO:
----------------------------------
* In all
other cases, if the selection results of from-spec (i.e.
source) and to-spec (i.e. destination)
are XML Infoset Items or data items in an
XML data model, and the XML Schema types of those
selections are known, then the source
value MUST possess the type associated
with the destination. Note that this does not require
the types associated with the source and
destination to be the same. In
particular, the source type MAY be a subtype of the
destination type. This kind of XML Schema
type checking can be done during static
analysis time or runtime or both. A BPEL
processor MAY perform static analysis of expression/query language
to check whether this compatible type
rule is observed and reject a process
definition if the rule is violated. When a BPEL
processor adopts an XML data model which
is XML Schema type aware, a BPEL
processor MAY perform the same check during runtime. If a
BPEL processor detects the violation at
runtime, bpws:mismatchedAssignmentFailure
fault MUST be thrown. However, since
XPath 1.0 data model is not schema aware, no XML Schema type
checking is performed at <copy>
operation during runtime, when the
default XPath 1.0 expression/query language binding is used.
----------------------------------
(B) Insert a new section on
"Selection Result of Copy Operations"
Insert a new section on
"Selection Result of Copy Operations" before the section of "Type
Compatibility ..." to state the replacement and XML information item nature
of <copy>. Here is the details of that section:
---------------------------------- Selection Result of Copy
Operations
There are 11 different types of information items in the
XML Infoset model. Most of them are not relevant in the context of XML data
manipulation as performed by <copy> operation. For example, Process
Instruction Information Item, Comment Infirmation Item and Document Type
Declaration Information Item.
The selection result of the from-spec
and to-spec used within <copy> operation MUST be one of the following
three information items: Element Information Item (EII), Attribute
Information Item (AII) or Text Information Item (TII). Note: EII and AII are
defined in [Infoset], while TII is defined to bridge the gap between
Inforset Model and other common XML data model, such as, XPath 1.0 data
model. Please see detailed definition of TII below.
If the selection
result of a from-spec or a to-spec belongs to other kinds of data items, a
bpws:selectionFailure fault MUST be thrown. Note that if any of the
unsupported Information Items are contained in the selection result they
will be preserved, the restriction is only that they cannot be selected
directly as the top level item by the from-spec or to-spec.
*Definition of Text Information Item (TII): * Text Information
Item (TII) is a sequence of zero or more CII according to the document
order. When it is mapped to XPath 1.0 model, it is a generalization of
String-Value (which has zero or more characters) and Text Node (which has
one or more characters). RValue of a TII can be mapped to a String-Value or
a Text Node in XPath 1.0, while LValue of a TII can be only mapped to a Text
node.
In WS-BPEL, <copy> operation is essentially a one-to-one
replacment operation. That implies the from-spec and to-spec MUST select
exactly one information item, which include the case of one TII. Also note
that this restriction means that literal values can only contain either a
TII or a single EII as its top level value..
----------------------------------
Adjust a bullet in section
"Assignment" to fit the clarification of TII definition FROM:
------------------------ a sequence of one or more character
information items: this is mapped to a Text Node in the data model of XPath
1.0 ------------------------ TO: ------------------------ a
sequence of zero or more character information items: this is mapped to a
Text Node or a String in the data model of XPath 1.0
------------------------
(C)
Insert a new section on "Replacement Logic of Copy Operations"
---------------------------------- Replacement Logic of Copy
Operations
Replacement Logic for WSDL Message Variables
When
the from-spec and to-spec of a <copy> operation select WSDL
message variables, the following replacement logic will be executed:
All existing message parts in the destination WSDL message variable
(referred by the to-spec) will be removed and all existing message parts in
the source WSDL message variable (referred by the from-spec) will be copied
and added to destination WSDL message variable.
Replacement
Table for XML Data Item:
When the from-spec and to-spec select one
of three information items, the following replacement table defines the
behavior of <copy> operation:
Src\Target
EII AII
TII EII RE
RC RC AII
RC RC
RC TII RC
RC RC
Definition
* RE
(Replace-Element-properties): Remove all [children] and
[attributes] properties of the
destination EII. Then, copy and add all
[children] and [attributes] properties of the source EII to
the desitnation EII. An optional
replaceElementName is provided to further
refine the behavior of <copy> operation:
o If
replaceElementName attribute at <copy> is set to "yes",
an
extra replacement step will be performed to replace the
target element-name with the source element-name. (i.e.
[namespace name] and [local name] properties).
o When
replacementElementName is set to "yes", the selection
result of from-spec and to-spec MUST be elements. A BPEL
processor MAY enforce this checking during static analysis
of
expression/query language. If violation is detected
during runtime, a bpws:selectionFailure fault MUST be thrown.
o The default of
this replaceElementName is "no" - not
replacing target element name.
o This attribute
is added to support subsitutionGroup pattern
in
XML Schema.
* RC (Replace-Content):
o How to obtain
the source content
+ The source (from-spec) MUST yield one and only one
node. Otherwise, selectionFailure fault MUST be
thrown. (That is, "selectionFailure" checking from
BPEL 1.1 is retained.)
+ After the node is yielded from the source, the
"string()" function will be applied to the node to
obtain its string-value as the source content, if the
default XPath 1.0 binding is used in the from-spec. If
the other expression language is used, a function
other than "string()" may be applied to the node to
obtain the source content
o How to replace:
+ If the source is an EII with an xsi:nil="true",
selectionFailure fault MUST be thrown. (That checks
are preformed during EII-to-AII or EII-to-TII copy).
+ If the destination is an EII, remove all [children]
properties (if any) and add the source content TII as
the child of the EII.
+ If the destination is an AII, replace the value of AII
with the TII from the source.
+ If the destination is a TII, replace the TII in the
destination with the TII from the source.
Note: Information items
referenced by the to-spec MUST be a Lvalue. In XPath 1.0 data model, only
Text Node can constitute a LValue of TII.
Using <copy> to
initialize variables When the destination selected by to-spec in
<copy> is uninitialized, the destination variable or message part will
be initialized first before executing the above replacement logic. Details
of initialization are:
* For complex type and
simple type variables, a skeleton structure,
composed of a DII and an anonymous EII
(Document Element), will be created as an
integral part of the initialization <assign>/<copy>
operation. After the skeleton structure,
the above "replacement" logic can be
reused. * For element based variables, a skeleton
structure, composed of a DII and an EII
(Document Element) with the name matching the
element name used in variable
declaration, will be created as an
integral part of the initialization <assign>/<copy> operation.
After the skeleton structure, the above
"replacement" logic can be reused.
* For message part, the above two pieces of logic is
reused, since a message part is either of
a simple type, a complex type, an element.
Handling Non-Infoset
Data Item in <copy>
Simple type variables and values are
allowed to manifested as non-Infoset data objects, such as, boolean, string,
float defined in XPath 1.0. Also, some expressions can yield such a
non-Infoset data object. For example:
<from>
number($order/amt) * 0.8 </from>
To consistently apply the
replacement logic defined above, these non-Infoset data is handled as if
they are Text Infoset Item (TII). The handled-as-TII logic is achieved
through "to-string" data conversion, as TII resembles a string object.
To be more specific, when XPath 1.0 data model is used in WS-BPEL,
the "string (object)" will be used to convert boolean or number object to
String / TII. ( http://www.w3.org/TR/1999/REC-xpath-19991116#function-string
)
Please note: the conversion is used to describe the expected
result of <copy>. A WS-BPEL processor MAY skip the actual conversion
for optimization if the result of <copy> remains the same and the
conversion is redundant.
XML Namespace Preservation During
<copy> operation, the [in-scope namespaces] properties (similar to
other XML Infoset Item properties) from the source MUST be preserved in the
result at the destination. When variables are serialized into the XML-based
text form, a WS-BPEL processor will make use of a namespace-aware XML
infrastructure will add xmlns related attributes in XML-based text.
Given the replacement logic definition above, there are no true
conflicts of XML namespace declaration between the source (i.e. selection
result of from-spec) and destination (i.e. self-or-parent of the selection
result of to-spec) in most of cases. XML namespace mechanism is flexible
enough to handle those cases. For example:
<foo:bar xmlns:foo="http://foo.com"> <!--
this "foo:bar" element is pointed
by to-spec as the destination
of copy --> <foo:abc xmlns:foo="http://foo2.com"
/> <!-- this "foo:bar" element is pointed
by to-spec as the destination
of copy --> </foo:bar>
However, there are some cases
where a non-trivial conflict rises. For example: v1: <foo:bar
xmlns:foo="http://foo.com" foo:attr="valueA" /> v2:
(before copy) <p:parent xmlns:p="http://foo.com" xmlns:foo="http://foo.some.com">
<p:bar foo:attrX="valueY" />
</p:parent>
With the following copy operation, there would
be conflict of prefix usage of "foo" used in foo:attr and foo:attrX, which
are associated with "http://foo.com" and "http://foo.some.com":
<assign>
<copy>
<from>$v1</from> <to
xmlns:p="http://foo.com">$v2/p:bar</to>
<copy> </assign>
To resolve
conflict, the underlying namespace aware infrastructure is allowed to rename
prefixes to non-conflicting ones if necessary. For example, after the copy
operation is done, V2 may look like the following:
v2: (after copy)
<p:parent xmlns:p="http://foo.com" xmlns:foo="http://foo.some.com">
<p:bar xmlns:foo2="http://foo.com" foo2:attr="valueA" />
</p:parent>
or
<p:parent xmlns:p="http://foo.com"
xmlns:foo="http://foo.some.com">
<p:bar p:attr="valueA" /> </p:parent>
Details of renaming prefixes are dependent on the underlying
namespace aware infrastructure and they are outside of the scope of this
specification. As the above example illustrates, there are usually more than
one way to rename prefixes to handle this conflict to produce XML namespace
consistent data.
When a schema-aware data model is used at runtime
in WS-BPEL, similar prefix renaming mechanism may be used to handle
namespace declaration conflicts in usage situation of QName values of
attribute or text forms.
----------------------------------
In section "Assignment", change the <copy> syntax
FROM: --------------------------
<copy>
from-spec
to-spec
</copy>
-------------------------- TO: --------------------------
<copy
replaceElementName="yes|no"?>
from-spec
to-spec
</copy>
--------------------------
Insert a paragraph before the
paragraph starting with "An optional validate attribute can be used with the
assign activity" as follows: -------------------------- An optional
replaceElementName attribute at the <copy> construct can be used to
specify whether the element name of the destination (selected by to-spec)
will be replaced by the element name of the soruce (selected by from-spec)
during the copy operation. For details, please see section "Replacement
Logic of Copy Operations". --------------------------
END
|