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

Re: [LC] 11.1 The submission Element (PR#76)

From: John Boyer <xforms-issues@mn.aptest.com>
Date: Thu, 26 Jul 2007 16:49:35 -0500
Message-Id: <200707262149.l6QLnZTb021475@htmlwg.mn.aptest.com>
To: Steven.Pemberton@cwi.nl
CC: www-forms-editor@w3.org

Hi Steven,

Thank you for submitting the last call comments below.  The working group has
resolved the issues as described by the inline comments below.  Please see the
editor's draft of XForms 1.1 available from the Forms WG home page and let us
know if you have any further concerns about these issues.

Thank you,
John Boyer

> 
> http://www.w3.org/TR/xforms11/#submit-submission-element
> 
> Resource attribute
> 
> The reader needs more help in deciding whether to use this or
> @action. This is sure to lead to confusion. In fact why not do away
> with the resource child and let this attribute be a value?
> 
> 	 <submission resource="concat('http://example.com/details/', country,  
> '/', city, '/')" ... />
> 

1) It has now been clarified @resource is the attribute to use going forward and
that action, while still supported, is deprecated.  The resource attribute
cannot be an XPathExpr because it is the new 'action' attribute and because that
would be inconsistent with use of @resource in other elements (load, instance). 
Moreover, the resource child element was added because this is consistent with
how we have allowed XPaths to override literal attributes throughout XForms 1.1.


> @method
> 	The allowable values should be listed.
> 

2) The allowable values of method were specified, but only in the core structure
chapter, not in the submission module chapter.  This has been corrected by
placing the table providing the overview of attributes and element content for
the submission element in the submission chapter.

> @verb
> 	Very difficult to understand what this does, and what a verb is. What
> are the allowable vaues?
> 

3) We agree that the verb element/attribute was confusing, and we have
restructured the 'method' to take over the functionality we intended for verb. 
This has significantly clarified the submission protocol operation and
submission data serialization.

> Note that the names @validate and @serialize are verbs, while @relevant is  
> an adjective (untidy difference).
> 

4) We agree that the attributes represent differnt parts of speech, but this is
generally true of all attributes of submission, and rationalizing them is
actually impossible since some are inherited from XSLT output, which has the
same issue.  Also, part of eliminating 'verb' involved deverbifying serialize;
it has become serialization.  In general, it seems that the real issue here is
that the name 'relevant' is perhaps not as good a name for what it names as are
validate and serialization (despite their being different parts of speech).  The
attribute controls whether or not the relevant MIP of data nodes are applied by
submission, which normally prunes from serialization data nodes whose relevant
MIP is false. Other names have been considered, such as 'prunenonrelevantnodes'
and 'prune', but these are either exacting but unwieldy or ambiguous.  The name
'relevant' was selected because it is clearly connected to the issue of
relevance, and as an attribute of submission, it seemed it would be easier for
readers to understand that it controlled the interaction between submission and
the relevant MIP.

> All the attributes need types and default values here.

5) All of the optional attributes of submission now have their default values or
behaviors specified.
Received on Thursday, 26 July 2007 21:54:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:15 GMT