W3C home > Mailing lists > Public > www-forms-editor@w3.org > June 2007

Re: Section 9 (PR#118)

From: John Boyer <xforms-issues@mn.aptest.com>
Date: Wed, 27 Jun 2007 17:34:51 -0500
Message-Id: <200706272234.l5RMYpqi002227@htmlwg.mn.aptest.com>
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.

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 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 - 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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:11 UTC