Re: last call comments for section 11 (PR#46)

Hi Aaron,

The working group has accepted and implemented fixes for these last call
comments.  Please see the editor's draft available from the working group home
page.

Further specific comments are placed inline below as needed.

Thanks,
John Boyer

> 
> The last of my last call comments.  Covers section 11.
> 
> 1) 11.1 - I'd reword the last sentence of the description for @mode,
> especially the last section of the sentence after the ','.
> 2) 11.1 - What are the valid possible values for @verb?  Not mentioned in
> the schema.  What is a 'submission protocol verb'?  Do you mean that it
> overrides @method?

Renamed verb to method to clarify that this is indeed true.

> 3) 11.1 - I'd suggest that the end of section 11.1 (before 11.2) is a good
> place to list the 'worker elements' that can appear as children since this
> information can't be found in the schema.

done, although the schema will also be updated.

> 4) 11.2 - extraneous ')' in the second sentence.
> 5) 11.2 - #2 - So even if @relevant="false", we can't bind xf:submission to
> a non-relevant node?  That seems counter-intuitive.

Fixed.

> 6) 11.2 - second bullet after #8 - Missed capitalizing 'if' which starts
> the sentence, "If the parse fails, then submission processing concludes..."
> 7) 11.7.2 - the first sentence doesn't make sense.  Perhaps it should read,
> "The submission element can optionally <contain> a child element named
> verb..."
> 8) 11.8 - what about header information that might be determined also by
> other things?  Like charset?  Does that also override?  What if header
> information is duplicated?

The next sentence after the one to which you refer explains that the headers are
appended to those available by other means i.e. the underlying user agent.
The one "override" to which we refer is an instance where *XForms* is overriding
a header that *XForms* generates via another means. Otherwise, there are no
overrides.  Basically, the headers are not processed by XForms, so the
interaction of the headers generated by XForms with those obtained by other
means is not under the control of XForms.

> 9) 11.8.1 - also other places where the new worker elements live - what if
> @value is an invalid xpath expression?  No xforms-compute-exception?  Or
> any other kind of error?

Throughout the spec (i.e. not just in submissions), the failure to evaluate an
XPath in a value attribute results in just using the empty string.  Processing
is not halted with an exception (and no appropriate exception is currently
defined for cases like this).

> 10) 11.9 - the sentence right before the serialization table - the word
> 'attribute' is duplicated.
> 11) 11.12 - third bullet - extraneous 'as' in "Element nodes selected for
> includesion are as encoded as ..."
> 12) 11.19.3 - fifth bullet - should probably be 'changed', not 'change' in
> "...header is change to text/xml"
> 
> Good luck finishing up the 1.1 work!
> --Aaron
> IBM Corporation
> Internal Zip: 9022D016
> 11501 Burnet Road
> Austin, TX 78758
> (512)838-9948
> inet: aaronr@us.ibm.com
>    _
>   (} @
>   |=     Volleyball Rules!!!
> /\
> 
>

Received on Tuesday, 11 September 2007 10:13:35 UTC