W3C home > Mailing lists > Public > public-forms@w3.org > December 2011

Re: @initial MIP

From: John Boyer <boyerj@ca.ibm.com>
Date: Thu, 1 Dec 2011 09:03:32 -0800
To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Cc: Forms WG <public-forms@w3.org>, Steven Pemberton <Steven.Pemberton@cwi.nl>
Message-ID: <OF322E5AE5.42C6D2C6-ON88257959.005C984B-88257959.005DB642@ca.ibm.com>
Hi Steven (and Nick),

Adding an attribute where one does not now exist is a structural change. 
At the current time, it is the case that all structural changes have easy 
to characterize/recognize (for the form author) properties, like 
corresponding to an insert or delete action and trackable by an 
xforms-insert or xforms-delete event on the instance.

Would such events still occur by this new mechanism?  If not, there are 
current form patterns that will break down, and we'll need the proponents 
of this feature to think about a replacement.

That being said, there seems to be no compelling reason to add a new 
feature when we already have this feature.

Write an xforms-model-construct-done handler and put an xforms:insert into 
it that conditionally runs in case the attribute is absent.  The origin 
attribute can invoke the new attribute() function to create the attribute 
without needing it to preexist somewhere.  By this mechanism, we still get 
an attribute and it is initialized properly, but it also hooks into the 
normal structural change mechanism so that it remains easy to both find 
and track structural changes in xforms documents.

John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 

From:   Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
To:     Steven Pemberton <Steven.Pemberton@cwi.nl>
Cc:     Forms WG <public-forms@w3.org>
Date:   01/12/2011 02:31 AM
Subject:        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 

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" 

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:

(image/png attachment: 01-part)

(image/png attachment: 02-part)

(image/png attachment: 03-part)

Received on Thursday, 1 December 2011 17:04:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:48 UTC