[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, 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 >> >> >> > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]