[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 157 Proposal - August 17 Revision
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]