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
|
