- 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