[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 51 - Generalization of bpws:mismatchAssignmentFailure fault- [Fwd: Re: [wsbpel] Issue 157 Proposal - August 17 Revision]
During Issue 51, we need to clarify whether we want to generalize
bpws:mismatchAssignmentFailure fault.
Thanks!
Regards,
Alex Yiu
-------- Original Message --------
Subject: Re: [wsbpel] Issue 157 Proposal - August 17 Revision
Date: Thu, 25 Aug 2005 13:07:09 -0700
From: Alex Yiu <alex.yiu@oracle.com>
To: chris.keller@active-endpoints.com
CC: 'Yuzo Fujishima' <fujishima@bc.jp.nec.com>,
wsbpel@lists.oasis-open.org, 'Charlton Barreto' <cbarreto@adobe.com>,
'Danny van der Rijn' <dannyv@tibco.com>, 'Yaron Y. Goland'
<ygoland@bea.com>, 'Diane Jordan' <drj@us.ibm.com>, Alex Yiu
<alex.yiu@oracle.com>
References: <200508251347.j7PDlwSv031277@rgminet04.oracle.com>
Hi all,
On 1), I agree with Chris also.
On 2), I don't have a strong opinion on which fault needs to be thrown.
I would be a democratic person in this case. Since Yuzo and Chris has a
preference for mismatchAssignmentFailure fault. I have no problem to
restate the friendly amendment as follows:
-------------------------------
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:mismatchAssignmentFailure* fault MUST be thrown.
-------------------------------
We can retouch this mismatchAssignmentFailure fault issue during Issue
51 or a new bug issue to track this down. I prefer giving a closure to
Issue 157.
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
>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:fujishima@bc.jp.nec.com]
>Sent: Thursday, August 25, 2005 2:53 AM
>To: Alex Yiu
>Cc: chris.keller@active-endpoints.com; wsbpel@lists.oasis-open.org;
>'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:alex.yiu@oracle.com]
>>>*Sent:* Wednesday, August 24, 2005 3:35 PM
>>>*To:* wsbpel@lists.oasis-open.org <mailto: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-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:cbarreto@adobe.com
>>>+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
>
>
>
>
>
>
>---------------------------------------------------------------------
>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]