1.1 Last Call comments

Hi all,

I'm sorry that this is so late.  Been crazy here trying to get our latest
Mozilla XForms extension release out.  I'm also sorry that this only covers
sections 1-9.  That is as far as I've gotten.  But here is what I've come
up with on those sections:

1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it
was better defined.  But it is still there.
2) Section 2 mentions 'HTML forms' and 'HTML Forms'.  The capitalization
probably needs to be consistent throughout the document.
3) Section 2.1, "It is clear that we are collecting a value tht represents
whether cash or credit card is being used..."  Probably need to say
'...cash or a credit card...' just to be more grammatically correct.
4) Section 2.3, "...because the evaluation context nodes for computed
expressions are determined by the bind ref binding expression..."  ref
should be nodeset here, since @ref isn't valid on a xf:bind.
5) Section 3, Document structure - mentions XHTML 1.0.  Shouldn't that be
XHTML 2.0?
6) Section 3.2.3 and 3.2.4 - the string 'IDREF' is used in different fonts
at different times but it seems to me it is used the same way in both
cases.  For example, the phrase "or a bind IDREF value that refers to an ID
not on a bind element" is used in both sections and in one place 'id' is
used, in another 'ID' is used.  And in one place IDREF is in a fixed font
and in the other it looks like the default font.  It gets confusing.
7) Section 3.3.1 "has no predefined behavior event-based behavior."
Doesn't make sense having 'behavior' here twice.
8) Section 3.3.1 - "If any non-default model has a versoin..." version is
misspelled.
9) Section 3.3.2 - resource attribute - you are introducing a new attribute
to the instance element and don't have it in the 1.1 schema?  You could
also break the xforms out there that currently use @src on the instance
element.  -> Section 3.2.2 says that the host language can allow @src on
xforms elements, for example.  So what should happen if @src and @resource
are on the element?  Who wins?  The text in 3.3.2 says that the host
language linking attribute 'MAY' win.  That doesn't help anyone.  How is a
form author supposed to code to that?  Seems to me like this change needs
more thought.
10) Section 3.3.2 - incomplete sentence -> "If the host language may treat
failure to traverse the link as an exception" is an incomplete sentence.
11) Section 3.3.2 - "All data relevant to the XPath data model must be
preserved during processing and submission, including processing
instructions, comment nodes and all whitespace".  What about if @indent is
specified on xf:submission?  Whitespace won't be preserved during
submission then.
12) Section 3.3.4 - "Element bind selects a node-set selected from the
instance data" seems like poor wording to me.  Why not just say, "Element
bind selects a node-set from the instance data"?
13) Section 3.3.4 - two periods terminating the sentence right before
section 3.4.
14) Section 3.5 - "Another common approach is to allow unregulated content
in a few selected places."  Should probably be "...in a few select places."
15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if
there is a host-language defined linking attribute.
16) Section 4.3.2 - mentions the special case of focusing a repeat, but not
the special cases of group and switch.  Why not?
17) Section 4.3.5 - "...then either the xforms-valid event must be marked
for dispatch if the node changes from valid to invalid..." I assume that is
a typo?  Other way around, I'd think.
18) Section 4.3.6 - the paragraph that mentions 'circular dependency' is
pretty confusing on the whole.  Could really use an example or two,
especially the circular dependency part.
19) Section 4.6.9 - doesn't mention the xforms-submit-serialize event.
20) Section 4.7.1 - I found the second paragraph very confusing.
21) Section 4.7.2 - "However, if the target bind element has one or more
bind element ancestors, then the identified bind may be a target element
that is associated with more than one target bind object."  Huh?
22) Section 7.2 - Shouldn't hasFeature return 1.1?  Otherwise how do I know
if the processor handles 1.1 stuff?
23) Section 7.4 - Double periods terminating the second sentence in the
first paragraph.  Space before the period terminating the third sentence in
the first paragraph.
24) Section 7.8.5 - "The general method described in Resolving ID
References in XForms is used to determine the desired run-time case
object".  I assume you mean repeat object?
25) Section 7.11.4 - "The node-set parameter provides nodes in one or more
documents to be searched."  Can you give an example of how to specify a
nodeset that applies to more than one document?
26) Section 8.1.1 - "If a form control violates its data binding
restriction, an xforms-binding-exception must occur."  How can a form
control violate its data binding restriction?  I would think that the bound
data would violate the data binding restriction of the control.
27) Section 8.1.1 - a bulleted list of "Form control must..." items, but no
examples.  Any suggestions for  how I would "...render upon request an
explanation of the current state of a form control..."?  And what is the
request?
28) Section 8.1.1 - the list of events that happen when a form control goes
from being irrelevant to relevant -> xforms-value-changed only MIGHT be
generated.  A control can become relevant without the value of the
control's bound node changing at all.
29) Section 8.1.5 - the description is duplicated.
30) Section 8.3.3 - "This required element labels the containing form
control with a descriptive label."  This isn't always required.  For
example repeat, output, choices, group, and case.
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.
32) Section 9.2.3.1 - no schema change to show that @value is a possible
attribute of case element.
33) Section 9.3.1 - "if an element of the collection is non-relevant..."
The 'if' starts the sentence but isn't capitalized.
34) Section 9.3.1 - homogeneous collection example - the delete action
should be handling a DOMActivate event, not an 'activate' event.
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)?
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.
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.
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.
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.

--Aaron
IBM Corporation
Internal Zip: 9022D016
11501 Burnet Road
Austin, TX 78758
(512)838-9948
inet: aaronr@us.ibm.com
  _
 (} @
 |=     Volleyball Rules!!!
/\