- From: John Boyer <xforms-issues@mn.aptest.com>
- Date: Wed, 27 Jun 2007 17:34:51 -0500
- To: aaronr@us.ibm.com
- CC: www-forms-editor@w3.org
Hi Aaron, This is a response to several issues you raised in your last call comment email dated April 30. Two of the issues in the sequence 31-39 have been flagged as separate issues, but I listed them below so you would know they weren't skippped accidentally. Please let us know if you have any further concerns about the other issues that are addressed below. You can see the results of the fixes in the editor's copy of the spec available from the Forms WG website. Thanks, John Boyer 31) Section 9.2.2 - no mention of the possible "value" attribute or its potential behavior as a child toggle. Should at least be a nod to it. Yes. This is because the case element child of switch (defined in 9.2.2) does not have a value attribute. Section 9.2.3.1 defines the case element child of toggle, which is a completely separate element. It has the same tag name, but a different parent. That is the case element that supports the value attribute (and not the selected attribute). 32) Section 9.2.3.1 - no schema change to show that @value is a possible attribute of case element. The schema will be changed. 33) Section 9.3.1 - "if an element of the collection is non-relevant..." The 'if' starts the sentence but isn't capitalized. Fixed. Not diff-marked. 34) Section 9.3.1 - homogeneous collection example - the delete action should be handling a DOMActivate event, not an 'activate' event. Fixed, not diff-marked. 35) Section 9.3.2 - how should we handle XML event handlers contained at root level under a repeat or a non-xforms element with repeat attrs? Like itemset (listeners registered on the repeat rows and not on the repeat itself)? This has been filed as a separate issue and will be answered later. 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions contained by an itemset to handle events on the itemset." It seems odd that an XForms action OUTSIDE the itemset can handle events on the itemset. And non-XForms actions in the itemset won't be repeated under the anonymous items. For example, the xhtml or xml events 'handler' element would be nice to have repeated to allow the form author to handle xforms-select and xforms-deselect events with script. This has been filed as a separate issue and will be answered later. 37) Section 9.3.5 - if we are inserting attributes, why does the order matter? I didn't think that attribute order was guaranteed to be honored in DOM. Fixed. Diff-marked. For attributes, we define the target location as the full attribute axis, so that the insertion does not specify where the new attribute nodes will go. We believe Xpath supports identifying an attribute by position at a moment in time, but we agree that it may not be possible for an implementation to guarantee the positioning across a mutation of the data model. 38) Section 9.3.5 - the example with the repeat - there needs to be @id="R" on the repeat or the example won't work since the xf:insert uses the index() XPath extension function. Fixed. Not diff-marked. 39) Section 9.3.7 - "if the index evaluates to NaN the action has no effect." The 'if' starts the sentence but isn't capitalized. Fixed. Not diff-marked.
Received on Wednesday, 27 June 2007 22:38:47 UTC