- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Thu, 07 Feb 2019 17:48:31 +0100
- To: "Erik Bruchez" <ebruchez@orbeon.com>, "Steven Pemberton" <steven.pemberton@cwi.nl>
- Cc: XForms <public-xformsusers@w3.org>, "XForms Users Community Group Issue Tracker" <sysbot+tracker@w3.org>
- Message-ID: <op.zwuoy5y6smjzpq@steven-xps>
> * for a constraint expression, the result is false();
> * for other bind computed expressions, the result is not applied to the
> node;
Those others are: readonly, required, and relevant.
In other words they get their default values.
readonly: false unless calculate is used
required: false
relevant: true.
(The default for constraint is true).
So we have:
<bind ref="a" constraint=")("/> a is invalid
<bind ref="a" readonly=")("/> a is read/write
<bind ref="a" required=")("/> a is not required
<bind ref="a" relevant=")("/> a is relevant
Do we agree? How about we just say that evaluation gives false() in all
cases?
> If the evaluation of an expression fails because of a type error:
This surely applies to all expression evaluation errors, doesn't it?
Steven
On Wed, 06 Feb 2019 11:34:09 +0100, Steven Pemberton
<steven.pemberton@cwi.nl> wrote:
> OK, how about:
>
> "Types in XForms are principally used to check the validity of strings
> provided as values >to nodes.
> However, these types can also be used by the expression language when
> evaluating >expressions using nodes; the XForms processor should
> therefore provide the typed values of >nodes to the expression
> evaluator, and not just the strings.
>
> If the evaluation of an expression fails because of a type error:
> * for a calculate expression, the result is the empty sequence;
> * for a constraint expression, the result is false();
> * for other bind computed expressions, the result is not applied to the
> node;
> * for all other expressions, an xforms-expression-error event is
> dispatched to the element containing the expression."
>
> Steven
>
> On Wed, 06 Feb 2019 07:32:23 +0100, Erik Bruchez <ebruchez@orbeon.com>
> wrote:
>
>> This is my response to "ACTION-2216: XForms: Erik to review 2nd part
>> and see if Steven's >>understnding is right, if there is too much text
>> in the spec".
>>
>>> The other is section 6.2 Typed Values
>>> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#Typed_Values
>>> which I now realise I don't understand the purpose of entirely.
>>>
>>> I think the argument is
>>>
>>> "Types in XForms are principally used to check the validity of strings
>>> provided as values to nodes. However, the expression language may also
>>> use those types during the evaluation of expressions using those nodes.
>>>
>>> If the evaluation of an expression fails because of a type error:
>>> * for a calculate expression, the result is the empty sequence
>>> * for a constraint expression, the result is false()
>>> * for other bind computed expressions, the result is not applied to
>>> the node
>>> * for all other expressions, an xforms-expression-error event is
>>> dispatched to the element containing the expression."
>>>
>>> Do you think there is any other part of that section that is normative
>>> that I have missed?
>>
>> I don' think that's quite enough. We should also tell how "the
>> expression language may >>also use those types during the evaluation of
>> expressions using those nodes" in case >>there is not a type error.
>> Mainly, this means that with XPath 2, the processor must >>expose the
>> typed values of nodes when nodes are atomized or accessed with the
>> `data()` >>function.
>>
>> -Erik
Received on Thursday, 7 February 2019 16:49:01 UTC