← Prev in month
← Prev in thread
RE: [wsbpel] Issue 157 - proposal
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. mailto: +1.408.536.4496p From: Alex Yiu [mailto:] Sent: Tuesday, August 02, 2005 3:07 PM To: Cc: ; Charlton Barreto; Alex Yiu Subject: Re: [wsbpel] Issue 157 - proposal draft 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 WS-BPEL_Issue_157_Proposal_with_changelog.doc WS-BPEL_Issue_157_Proposal.doc
← Prev in month
← Prev in thread