Re: last call comments for Section 10 (PR#47)

Aaron,

all issues except for 3), 16) and 19) are considered to be editorial and we will
fix the spec accordingly.

Regarding issue 3) we change the spec language so that delay="" is the default
and means synchronous dispatch with no delay; and delay="0" is asynchronous, and
delay as a positive integer is a delay as currently specified.

Regarding issue 16) we agree that the in-scope evaluation context is determined
statically, by the lexical position of the handler definition, and so the
secondModel default submission will be used.

Regarding issue 19) we decided to mirror message.

Regards,
Ulrich Nicolas Lissé.
For the Forms WG

> 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!!!
> /\
> 
>

Received on Friday, 15 June 2007 15:05:50 UTC