[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 157 - proposal
Attached are my comments on the proposal. Thanks, Yaron Charlton Barreto wrote: > > 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 p lease don't hestitate to contact Alex or > myself if you have any questions. > > Cheers, > > -Charlton. > > Adobe Systems, Inc. > mailto:cbarreto@adobe.com > +1.408.536.4496p > > > *From:* Alex Yiu [mailto:alex.yiu@oracle.com] > *Sent:* Tuesday, August 02, 2005 3:07 PM > *To:* ygoland@bea.com > *Cc:* wsbpel@lists.oasis-open.org; 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"; <http://foo.com>> <!-- this >>> "foo:bar" element is pointed >>> by to-spec as the destination of copy --> >>> <foo:abc xmlns:foo="http://foo2.com"; <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"; <http://foo.com> >>> foo:attr="valueA" /> >>> v2: (before copy) >>> <p:parent xmlns:p="http://foo.com"; <http://foo.com> >>> xmlns:foo="http://foo.some.com"; <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"; <http://foo.com> and "http://foo.some.com"; >>> <http://foo.some.com>: >>> >>> <assign> >>> <copy> >>> <from>$v1</from> >>> <to xmlns:p="http://foo.com"; <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"; <http://foo.com> >>> xmlns:foo="http://foo.some.com"; <http://foo.some.com>> >>> <p:bar xmlns:foo2="http://foo.com"; <http://foo.com> >>> foo2:attr="valueA" /> >>> </p:parent> >>> >>> or >>> >>> <p:parent xmlns:p="http://foo.com"; <http://foo.com> >>> xmlns:foo="http://foo.some.com"; <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.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]