[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 157 Proposal - August 17 Revision
+1 to Charlton. I am going to forward one of my previous 157 email to 51 thread for the ease of keep tracking. Thanks! Regards, Alex Yiu Charlton Barreto wrote: > Hi all, > > I would prefer this form of the amendment - and strongly prefer to > dig into the issue of bpws:mismatchAssignmentFailure outside of Issue > 157 - best to either address it in Issue 51 or on its own as > suggested by Alex. > > -Charlton. > > On Thu, 25 Aug 2005 13:07:09 -0700, Alex Yiu <alex.yiu@oracle.com> wrote: > >> >> 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]