Re: Big update to XForms 1.1 spec; Ready for your review

Dear Working Group Members,

Reviewing the spec resulted in the follwing remarks:

4.4.11 The xforms-readonly Event and 4.4.12 The xforms-readwrite Event
Is group not a valid target for the xforms-readonly and xforms-readwrite 
events?

6.1.2 The readonly Property
Previously section 6.1.2 The readonly Property[1]  clearly stated that 
"When evaluating to true, this model item property indicates that the 
XForms Processor should not allow any changes to the bound instance data 
node." And I know for certain that Chiba, the Firefox extension,… block 
the setvalue action from changing read-only content. I know that it is 
hard to enforce this if you provide direct access to the DOM through 
script. But I don't think we should sacrifice the nice separation in our 
MVC architecture, the model needs to be the one that enforces the 
read-only property both to the View (the UI) and the controller (the 
actions). I know that the previous wording needs some tweaking because it 
doesn't say if a submission is allowed to replace inside read-only 
content, and if it isn't allowed what exception is dispatched. But it 
clearly states that no changes are allowed, we should think twice before 
changing this. It breaks backwards compatibility, is counter intuitive (at 
least for me) and in my personal view breaks the principle that data 
integrity is enforced by the model. If we really want a UI read-only 
attribute it should live in the UI and be an attribute on the form control 
and not on the binding in the model.

9.3.3 Repeat Processing
The new text introduces the concept of a 'repeat object'. And says that 
"The capture and bubble phase of XML Events dispatched to these run-time 
objects is confined to the repeat object." Does 'confined to the repeat 
object' mean that the events don't start at the root of the xforms 
document when the capture phase begins and ends back at the root after the 
bubble phase? 

9.3.6 The itemset Element
There is currently at least one implementation (Chiba) that enrolls the 
repeated item elements inside the document DOM, and where the events flow 
from the root of the xforms document to the element inside the item and 
bubble up to the root afterwards. Is this the only implementation that 
does this? And why is it conceptually wrong to let the event capture and 
bubble from the root of the xforms document.

Minor remarks:

3.3.2 The instance Element
Last sentence is redundant; the second sentence already handles the case 
of both inline content and resource attribute being present :
"If the src attribute is given, then it takes precedence over inline 
content and the resource attribute, and the XML data for the instance is 
obtained from the link. If the src attribute is omitted, then the data for 
the instance is obtained from inline content if it is given or the 
resource attribute otherwise. If both the resource attribute and inline 
content are provided, the inline content takes precedence."

4.2.2 The xforms-model-construct-done Event [1]
Before the text mentioned 'binding expression' of form controls, this is 
changed to 'single node binding expression'. But the repeat element is a 
form control and  has a 'node set binding' not a 'single node binding'.

8.1.1 Implementation Requirements Common to All Form Controls
Missing has in the first Note ("Form controls that read or write 
simpleContent produce this exception whenever and as soon as they are 
bound to an element node that an element child node.")

9.3.3 Repeat Processing
Second note ends in the middle of the sentence 'An event handler that 
listens for xforms-insert on model in the capture phase and'

10.2 The setvalue Element
Missing word in "the element will have either a single non-empty text node 
child, or no children string was empty." Should be 'or no children __if 
the__ string was empty'.

11.1 The submission Element
Typo : should be 'has' instead of  hsa : "If the omit-xml-declaration 
attribute hsa the value true,"

Regards,

Nick Van den Bleeken  -  Research & Development
Inventive Designers
Phone: +32 - 3 - 8210170
Fax: +32 - 3 - 8210171
Email: Nick_Van_den_Bleeken@inventivegroup.com
[1] 
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-processing


public-forms-request@w3.org wrote on 08/17/2007 07:45:48 AM:

> 
> Dear Working Group Members, 
> 
> Due to the struggles we have long been having with certain issues as
> well as the need to address certain last call comments, I felt it 
> was necessary to do a much better job of specifying certain 
> pervasive concepts in XForms.  My hope was to really try to help 
> "take us to the next level" of rigor in order to make it easier to 
> fully implement 1.1 as well as figure out how to add more features 
> in 1.2 and 2.0. 
> 
> Luckily I get to run for the hills for two weeks while you decide 
> how you feel about the new content.  But seriously, I've really put 
> a lot of work into this, and I think you will like the results (even
> if you don't agree with every last detail of it :-). 
> 
> Please see the "editor's draft" diff-marked version here: http:
> //www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html 
> 
> Here are the important types of changes that I made that you should 
> be looking for: 
> 
> 1) FORM CONTROLS 
> 
> I created definitions for "core form controls" (the things in 
> chapter 8 that provide UI points of direct interaction with the end-
> user) and "container form control" (the group, switch and repeat 
> objects in Chapter 9).  This allowed me to define "form control" as 
> the union of the two. 
> 
> In turn, these definitions required me to hunt down all 315 
> occurrences of form control and make sure it was being used 
> correctly.  See in particular the Processing Model chapter, which 
> contains descriptions of all our events.  The ones targetted at 
> "form controls" in the past had to be looked at carefully to define 
> what the real targets should be. 
> 
> This was really necessary in order for me to fix things like 
> describing what it means to set the focus to a container form 
> control, which is a last call comment. 
> 
> 
> 2) REPEAT PROCESSING/EVENT FLOW IN REPEATED CONTENT 
> 
> This one is the mother lode. 
> It really started with incorporating Uli's changes to get rid of 
> "homogeneous collection".  He did a great job of switching over to 
> "repeat collection". 
> 
> It inspired me to rigorously define "repeat item" as node from the 
> collection, its position and size and a "repeat object", which was 
> defined as a group element that contains a set of run-time objects 
> created from a repeat template. 
> 
> This made it easy to say "set the focus to a repeat object" and mean
> set the focus to a group representing the set of controls, and then 
> setting the focus to a group (or switch) can be defined as 
> automatically handing focus to a contained control. 
> 
> Anyway, the "run-time objects" were defined as being actual form 
> controls so that it was clear you could really dispatch events to 
> them.  And having the repeat object be an actual group made it easy 
> to describe the XML eventing *within* the repeat object. 
> 
> All of these definitions made it much easier to describe the run-
> time mutation of a repeat to add or remove repeat items by various 
> means, including insert/delete, instance replacement and even by use
> of setvalue (in the case where the repeat nodeset contains dynamic 
> predicates). 
> 
> Armed with that, it was possible to describe repeat updating and 
> index manipulation on insert and delete as behaviors related to 
> xforms-insert and xforms-delete events.  Along the way, the inner 
> repeat index reinitialization cruft was, of course, removed 
> (retaining deletion diff marks and added notes to ensure it was 
> clear the behavior does not happen). 
> 
> Finally, that allowed me to move the insert and delete actions out 
> of the repeat module and into Chapter 10 Actions.  Of course, toggle
> and setindex followed, even though they are classified as actions 
> that are specific to their respective modules, the point remains 
> that ALL XForms actions are now in Chapter 10 (just as all 
> submission information is now comfortably in Chapter 11). 
> 
> 
> 3) MIP ENFORCEMENT 
> 
> I wrote diffs into all MIPs in Section 6 to explain the fact that 
> they do not impede the behavior of actions. 
> Although I provided good reasons why this is true, the points in 
> Erik's recent mail are even better than my own.  Faced with this 
> growing mound of irrefutable arguments, it seemed appropriate to 
> show you what the result looks like in spec-ready text. 
> This is related to the recent discussion about the readonly MIP, but
> the issue is applicable to all MIPs 
> 
> 
> 4) REMOVED "first text node" BEHAVIOR (per action item) 
> 
> Went through all the form controls to draw peoples attention back to
> the common processing rules for form controls, and in particular to 
> clearly call out in each form control that it should fail with 
> binding exception if it is supposed to bind to simpleContent. 
> 
> Then, defined exact behavior of binding to an element as reading the
> string of it and writing to it in such a way that it only has one 
> child text node left if the string being written is non-empty OR 
> zero child text nodes if the string is empty. 
> 
> While at it, I noticed that an unrelated problems happens with the 
> xpath data model if you bind directly to a text node and then write 
> the empty string.  The node goes away according to XPath.  I called 
> it out because it's true, but I'm sure it will make for some discussion. 
 
> 
> 5) FIXED OTHER SMALL ISSUES 
> 
> For insert and delete, the context attribute now applies even if you
> use a bind for the nodeset binding.  That was easy, and it makes a 
> lot more sense. 
> 
> Fixed small problem I introduced in insert a couple weeks ago while 
> accounting for the "root node" of XPath (the parent of the root 
element). 
> 
> Moved the DOM interface and hasFeature sections from Chapter 7 to 
> the end of Chapter 4. 
> 
> Did all the latest fixes to choose() that we recently agreed upon, 
> and I moved by choose() and event() to a new subsection for "Object 
Functions"
> 
> Pointed out in implementation requirements for element input that 
> the user should be prevented from entering multiline text (since 
> that's what textarea is for) 
> 
> Well, that's the bulk of what I can remember doing, anyway. 
> 
> See you in  a few weeks... 
> 
> John M. Boyer, Ph.D.
> STSM: Lotus Forms Architect and Researcher
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com 
> 
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer



-------------------------------------------
Inventive Designers' Email Disclaimer:
//www.inventivedesigners.com/email-disclaimer

Received on Tuesday, 21 August 2007 15:14:39 UTC