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
>>
>>
>>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
