Re: [wsbpel] Issue 157 Proposal - August 17 Revision

[Alex Yiu <alex.yiu@oracle.com>]

Hi Chris,

I understand your points ...  I don't have a strong opinion on which 
fault should be thrown for this particular case as of this moment. [ 
But, I still have a not-so-strong preference ... :-) ]

 From some viewpoints, it can be grouped to selectionFailure, because it 
is related to non-existence nature of data returned from the from-spec 
(i.e. empty string) and the after effect of <copy> operation. (i.e. text 
node becomes non-existent).

 From some viewpoints, it can be grouped to mismatchedAssignmentFailure, 
because it is related to certain undesirable combination between RValue 
item and LValue item. 

On the other hand, I would to add: mismatchedAssignmentFailure so far is 
reserved for _type mismatch_, not data value mismatch (which is our 
case; data type can be both string type). Quoted from spec:  "Thrown 
when incompatible types are encountered in an assign activity".

Also, selectionFailure has been generalized to report the cases of 
Document-II or Comment-II selection.

I guess it is a question which fault to be generalized.

Given we may touch the definition of "mismatchedAssignFailure" during 
Issue 51, how about taking "selectionFailure" for now? And, open a new 
bug issue to track whether "selectionFailure" should be replaced by 
"mismatchedAssignFailure" in this particular case. Let's tackle this 
which fault to throw issue after Issue 51 is resolved?

Would that work for you?


Thanks!


Regards,
Alex Yiu


Chris Keller wrote:

> Hi Alex,
>
>  
>
> I think selectionFailure may be the wrong fault to throw.  A 
> mismatchedAssignmentFailure may be the more appropriate fault.
>
>  
>
> From the spec:
>
>  
>
> selectionFailure:  Thrown when a selection operation performed either 
> in a function such as bpws:getVariableData, or in an assignment, 
> encounters an error.
>
>  
>
> mismatchedAssignmentFailure:  Thrown when incompatible types are 
> encountered in an assign activity.
>
>  
>
> - Chris
>
> ------------------------------------------------------------------------
>
> *From:* Alex Yiu [mailto:alex.yiu@oracle.com]
> *Sent:* Wednesday, August 24, 2005 3:35 PM
> *To:* wsbpel@lists.oasis-open.org
> *Cc:* Alex Yiu; Charlton Barreto; Danny van der Rijn; Chris Keller; 
> Yaron Y. Goland; Diane Jordan
> *Subject:* Re: [wsbpel] Issue 157 Proposal - August 17 Revision
>
>  
>
>
> Hi all,
>
> Requested by Danny, here I send the more formal wordings of the 
> friendly amendment to the TC list for the record:
>
> Add the following restriction to the proposal:
> -------------------------------
> When the to-spec selects a TII (e.g. Text node in XPath 1.0) as LValue 
> and one of the followings is computed or selected as RValue from the 
> from-spec:
>
>     * a TII which has zero Character Information Item
>     * an AII which has an empty string as its [normalized value]
>     * an EII which has zero Character Information Item as its
>       desendants, that is its [children] and nested [children]. (Note:
>       applying XPath 1.0 String() function to ths kind of EII would
>       yield an empty string)
>
> bpws:selectionFailure fault MUST be thrown.
> -------------------------------
>
>
> Thanks!
>
>
>
> Regards,
> Alex Yiu
>
>
>
>
> Alex Yiu wrote:
>
>
> I have uploaded these proposal docs to OASIS website as well.
>
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/14094/WS-BPEL_Issue_157_Proposal_Aug17.pdf
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/14095/WS-BPEL_Issue_157_Proposal_Aug17.doc
>
>
> Thanks!
>
> Regards,
> Alex YIu
>
>
> Charlton Barreto wrote:
>
> Attached are the .doc and .pdf formats for the August 17 revision of 
> the Issue 157 proposal, accepting Yaron and Monica's editorials and 
> Yaron's friendly amendment:
>
>  
>
> 1) Amendment: Remove Section (C) and incorporate that as the seed for 
> the Issue 51 discussion.
>
> 2) Editorial: Add language to express that a TII LValue cannot be empty.
>
> 3) Editorial: Remove "source" from "...as the name of the resulting 
> source element." in the first sub-bullet of the RE description in 
> Section (D) (which is now renamed as Section (C)).
>
>  
>
> Please let me know if you have any questions.
>
>  
>
> -Charlton.
>
> --
>
> Adobe Systems, Inc.
>
> mailto:cbarreto@adobe.com
> +1.408.536.4496p
>
>  
>
>  
>
>  
>
>  
>