[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 157 - proposal draft
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. "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. "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. "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. 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. "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. "(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. "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. "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. "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. 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]