[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 157 Proposal - August 17 Revision
Chris, 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). Oops! You are right. Yuzo > > 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 > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]