W3C home > Mailing lists > Public > public-xformsusers@w3.org > February 2019

Re: ACTION-2211: Redefine terms via xdm instead of xpath[1, 2]

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

This archive was generated by hypermail 2.3.1 : Thursday, 7 February 2019 16:49:02 UTC