last call comments for Section 10

Hi all,

Sorry, I only got through section 10 this weekend.  I'll try to get section
11 done in the next day or two.  Here is what I came up with:

1) Section 10 - under 'Deferred Updates' - first sentence has a space
before the period.
2) Section 10 - last sentence before section 10.1 - 'peformed' misspelled.
3) Section 10.2 - the 'delay' attribute - it mentions that the default
value is 0.  I would think that there might be some value for some xforms
processors to emulate JS's (and other systems ideas for timers like Windows
and OS/2) where a value of 0 is the shortest amount of delay possible but
it is still somewhat of a delay in that the processing could then be
performed on a separate thread.  Whereas if no delay attribute is specified
at all, then it would be performed immediately.  Just a thought.
4) Section 10.2.1 - first sentence - should probably be 'provides', not
'provide' since it is a singular noun.  Also I'm not sure if it should be
'an alternative means' or 'an alternate means'.
5) Section 10.2.2 - same as 10.2.1
6) The 'child elements' of the different actions like <name>, <target>,
<delay>, <control>, etc. are not defined in the schema.
7) I had a personal issue with the child elements like the ones I mentioned
in my #6.  They kind of interrupt the flow of the spec.  The action is
partially described (i.e. the special attributes are spelled out), then the
child elements are described in detail, then the behavior of the action is
described in detail.  But sometimes this behavior of the action is
described amongst the descriptions of the child elements.  It really needs
to be separated out.  It might just be me who sees this as an issue.  But I
think that if I am writing my action the old-styled way (i.e. using attrs
and not child elements) then I should be able to get all of the information
that I need without reading any part of the child element descriptions and
that the information I'd need would all be available BEFORE the child
elements are described.  For example, there is a lot of information about
how 'delay' works on a xf:dispatch...how an event is added to an event
queue and what to do if it is already on the queue.  This has nothing
specifically to do with the 'delay child element', but it is all described
in that section.  So if I were an author going through this spec trying to
figure out how I wanted to write my action, I'd have to read through almost
two pages of information before I get to that little tidbit.
8) Section 10.2.3 - the 'if' attribute is mentioned for the first time.  It
seemed to me that this popped out of the middle of nowhere.  I'd suggest
that 'if' and 'while' should be mentioned at least in passing in Section 10
where 'Conditional Execution of XForms Actions' and 'Iteration of XForms
Actions' are brought up.
9) Section 10.3 - first sentence - 'This action causes the processing of
xforms-rebuild to happen...'.  Maybe that would read better as '...the
default processing...' or '...the default action...'?  If so, this sentence
is used for the other RRRR events.
10) Section 10.8 - 'If neither a value attribute nor text content are
present, the effect is to set the value...'.  This sentence appears in the
second example for the setvalue element.  It seems to me that perhaps this
belongs in the main section describing setvalue rather than inside an
example where it could be overlooked.
11) Section 10.9 - 'Note that this event is implicitly invoked to implement
XForms accessibility features such as accesskey'.  This sentence seems to
pertain more to the xforms-focus event than to the setfocus element so
maybe it should be moved to that section instead of having it here?
12) Section 10.9.1 - 'The identity of the element to which the setfocus
action dispatches xforms-focus is is'...one to many 'is's.
13) Section 10.10 - @show - The 'if' that starts the second sentence needs
to be capitalized.
14) Section 10.10 - another example where the processing information is
mentioned after the possible child element.
15) Section 10.10.1 - The last sentence says, "If the load does not have a
resource element as its first child, then the URI is obtained from the
resource attribute or the Single Node Binding, if given."  That kind of
makes it sound like a toss up.  But Section 10.10.2 goes on to define even
more behavior in that area.  I think that the last sentence from Section
10.10.1 and the first paragraph from Section 10.10.2 need to be combined
together AND simplified.
16) Section 10.11 - @submission description - mentions 'If this attribute
is omitted, then the first submission in document order from the model
associated with the in-scope evaluation context is used'.  Similar wording
is used in other places in section 10.  How do you figure out the 'in-scope
evaluation context'?  If xf:send or any of these other xforms actions are
specified as a handler in a ev:listener, the xforms action could fire
because of an event reaching any one of a number of elements in the
document.  And how about if you have:

<xf:model id="firstModel">
...
</xf:model>

<xf:model id="secondModel">
...
</xf:model>


<xf:trigger id="myTrigger" model="secondModel">
  <xf:label>click to activate</xf:label>
  <xf:send id="mySender" ev:event="DOMActivate"/>
</xf:trigger>

<html:button id="myButton.../>
<ev:listener event="DOMActivate" observer="myButton" handler="#mySender"/>

The in-scope evaluation context if "myTrigger" is clicked, I believe, would
have the model being "secondModel" so now the first xf:submission will
happen from that model.  But what about if I click on the html:button?  The
in-scope evaluation would still be the secondModel, right?  Unless I missed
something specific about the evaluation contexts for actions.  But I'd
think that the submission that should happen would be the first
xf:submission from the default model (the first one).  Or am I missing
something?

17) Section 10.12 - There is a note about deferred update behavior and what
happens if a xf:output is inside a xf:message...that the refresh for the
output happens right away, but if the output depends on a recalc happening,
then the author has to call it specifically.  Should rebuild be mentioned
here, too?
18) 10.13 - I think that the first sentence for the prompt action element
needs to be reworded.  I find the first sentence confusing and then each
subsequent sentence goes into event behavior, bubbling, etc.  There needs
to be a better description of what a prompt is, I think.  Until I got to
the example where it makes it appear to be like a dialog box, I had no idea
what it was.  There needs to be some more descriptive text.  Like, perhaps,
"A form author can solicit simple feedback from the user by using a
xf:prompt.  A combination of labels and triggers, a prompt can be used to
halt the processing of a form until the user provides feedback by selecting
one of the triggers in the prompt.  Similar to a modal message."
19) Since labels are allowed in a xf:prompt and xf:outputs are allowed in
labels, can xf:outputs be used in a prompt?  If so, do they behave
similarly to how they behave in a xf:message?  In that they are
automatically refreshed when the xf:prompt starts handling the event?

I'll try to get to section 11 as soon as I have time.

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