Hi Yuzo,
On 1) I believe a TII in the to-SPEC won't be empty since the attempt to
select the node itself would have caused a selectionFailure (e.g. a query
like /a/b/text() returning an empty nodelist).
On 2) I agree my preference also is the mismatchedAssignmentFailure for the
same reason you mentioned.
- Chris
-----Original Message-----
From: Yuzo Fujishima [mailto:]
Sent: Thursday, August 25, 2005 2:53 AM
To: Alex Yiu
Cc: ; ;
'Charlton Barreto'; 'Danny van der Rijn'; 'Yaron Y. Goland'; 'Diane Jordan'
Subject: Re: [wsbpel] Issue 157 Proposal - August 17 Revision
Alex, Chris,
I have two comments/questions.
1. Will the fault result even if the to-spec TII is also empty?
In this case, deletion of an infoset will not happen; the infoset
doesn't exist from the beginning.
2. I prefer mismatchedAssignmentFailure.
If a user is presented with a selectionFailure, s/he will
probably check the from/to-spec XPaths only to find each is
valid per se and get confused.
Yuzo Fujishima
NEC Corporation
Alex Yiu wrote:
>
> 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:]
>> *Sent:* Wednesday, August 24, 2005 3:35 PM
>> *To:* <mailto:>
>> *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-BP
EL_Issue_157_Proposal_Aug17.pdf
>>
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/14095/WS-BP
EL_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:
>> +1.408.536.4496p
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
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
