OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 157 - updated and simplified replacement table


I had a few questions:

A) There is no specification for how namespace declarations from the 
source are merged with the destination in the case that the destination 
is an EII or AII. What rules are expected?

B) Shouldn't the reference to string() be struck and a pure infoset 
definition be used instead? E.g. "take all TII's in document order and 
concatenate them". That way we can stay away from any language specific 
issues like string() and xpath.

C) For an AII/TII to EII copy why are the attributes on the EII stripped 
before the copy is performed?

D) You define a TII as zero or more CIIs but that violates the 
requirement that the source and destination expressions produce a single 
information item since 'nothing' can't be an information item.

	Yaron

Alex Yiu wrote:
> 
> Hi all,
> 
> Upon the discussion of July 12 conf call, I have updated and simplified 
> the replacement table from the version that we sent out during the last F2F.
> 
> Please see the attached HTML file.
> 
> Thanks!
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Charlton Barreto wrote:
> 
>> At the July 12 call we:
>> 1) d iscussed the validity and usefulness of the EII for simple-type 
>> semantics, given concerns over handling of attributes between cases. A 
>> compromise of merging the EII for complex-type semantics and EII for 
>> simple-type semantics was discussed, and deemed acceptable to the 
>> group given a decision of whether we should always allow coercion of 
>> an element to text/TII, or always fault in this case. This decision 
>> was further discussed and polled, and it was agreed that we would give 
>> ourselves until July 22nd to converge on it via email. Barring that, 
>> we would hold an Issue 157 conference call on July 26 (08.00 PDT). In 
>> any case we will bring this issue to the TC on the July 27th 
>> conference call.
>> 2) discussed concerns over expression language independence. It was 
>> generally agreed that we protect such independence with Alex's Issue 
>> 157 proposal.
>> 3) questioned if we used a variable typed as XSD complex type, whether 
>> it would apply to the EII for complex-type or EII for simple-type 
>> semantics (as opposed to AII or TII). It was agreed that, as complex 
>> type will always be an element, and the content either complex or 
>> simple, it would apply to these semantics.  
>> 4) questioned that, given the lack of schema awareness, whether there 
>> was any way to distinguish between null and empty string, because of 
>> the lack of schema awareness? It was agreed that we don't distinguish 
>> between these two cases, as the runtime is not schema aware (if we'd 
>> want to distinguish it, we'd need to use XPath 2.0 instead of 1.0).
>>
>> As a result of 1), the existing proposal was amended to accomodate 
>> recommendations from others in the Issue 157 group:
>>
>>     * The first and second rows of the copy/replace semantics table
>>       (from the Palo Alto F2F) would be merged into one row for EII
>>     * EII-to-AII and EII-to-TII copy would be defined as copying the
>>       string-value of EII, instead of fault (except in the case of
>>       xsi:nil="true")
>>     * When xsi:nil="true" on an element, an EII-to-AII or EII-to-TII
>>       copy would trigger a selectionFailure
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> 
>     Issue 157 -  Discussion - Replacement Table
> 
> 
> Last modified: July 18, 2005 - 6 pm PDT
> 
> 
> Per conf call discussion on July 12, here is refined and consolided 
> version of the Replacement Table evolved from the F2F discussion.
> 
> 
>       Refinement and Consolidation of Replacement Table for <bpel:copy>
> 
> 
> Replacement Table:
> 
> 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 and add all
>       [children] and [attributes] properties of the source EII to the
>       desitnation EII
>           o If replaceElementName attribute at <bpel: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).
> 
>             (Note: for this "replaceElementName", please see the syntax
>             example below. This attribute is optional. The default will
>             be "no" - not replacing target element name. This attribute
>             is added to support XSD's subsitutionGroup pattern.)
> 
>     * 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 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
>                   will be replaced by the TII from the source.
>                 + If the destination is a TII, replace the TII in the
>                   destination with the TII from the source.
> 
> 
> *Foot-note to the "Replacement-Table"*:
> 
>     * Note: the above table does not describe the
>       message-variable-to-message-variable copy.
>     * Information items referenced by the to-spec MUST be a Lvalue. (As
>       stated in Issue 103)
>     * In XPath 1.0 data model, only Text Node can constitute a LValue of
>       TII.
> 
> 
> *Clarified Definition of TII: *
> TII is a sequence of zero or more CII. 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.
> 
> 
> Syntax Example of <copy> with "replaceElementName" attribute:
> ---------------------------
> <assign>
>    <copy replaceElementName="yes|no">
>          <from> ... </from>
>          <to> ... </to>
>    </copy>
> </assign>
> ---------------------------
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]