+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 <> 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:]
>>> Sent: Thursday, August 25, 2005 2:53 AM
>>> To: Alex Yiu
>>> Cc: ; ;
>>> '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:]
>>>>> *Sent:* Wednesday, August 24, 2005 3:35 PM
>>>>> *To:*
>>>>> <mailto:>
>>>>> *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:
>>>>> +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
>>>
>>>
>>>
>>
>
>
>
