Re: @initial MIP

If we allow predicates in the node expression it can become impossible to deterministically determine what the user wants. And for sure require some advanced XPath expression parsing.

There are simple cases like:

  <require node="foo[position() &lt= 5]/@bar" initial="...expression..."/> (make sure there are 5 foo elements, and initialize the bar element when it isn't on those foo elements)

(it will require some advanced XPath expression parsing to know what to do though)

But what will the following expression do if there are no foo elements with a baz attribute equal to 1 or 2:

  <require node="foo[@baz= '1' or @baz = '2']/@bar" initial="...expression..."/>

Should it create a new foo node with @baz attribute equal to 1, or should it be 2, or should we add the bad attribute to an existing foo node?

The downside of not allowing predicates is that you won't be able to declaratively ensure that a repeated structure with a minimal number of iterations is available on form load.

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office fax: +32 3 821 01 71<>


On 01 Dec 2011, at 11:19, Steven Pemberton wrote:

Nick and I noted that a form such as

<bind ref="foo/@bar" initial=""/>

intended to ensure that the foo element and its bar attribute both exist (in this case with no initial value) is a wrong use of @ref, since it works differently from how @ref works normally.

It is possible that we have to introduce a separate element for this use case, such as (strawman):

<require node="foo/@bar"/>
<require node="foo/@bar" initial="...expression..."/>

Nick also had some remarks about restrictions on the selector in @node, which I hope he will add in a reply to this.


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


Inventive Designers' Email Disclaimer:

Received on Thursday, 1 December 2011 10:30:57 UTC