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