XForms 1.1 Disposition of Comments

This note outlines the way in which the XForms Working Group has addressed comments received to date against working drafts of XForms 1.1

Status of this document

During the development of XForms 1.1, many public drafts of the document have been made available, and many public comments received. This document summarizes those comments and describes the ways in which the comments were addressed by the XForms Working Group.

Note that the majority of this document is automatically generated from the Working Group's database of comments. As such, it may contain typographical or stylistic errors. If so, these are contained in the original submissions, and the XForms Working Group elected to not change these submissions.

This document is a Note of the W3C's XForms Working Group. This Note may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Notes as reference material or to cite them as other than "work in progress". This document is work in progress and does not imply endorsement by the W3C membership.

Please send detailed comments on this document to www-forms-editor@w3.org. We cannot guarantee a personal response, but we will try when it is appropriate. Public discussion on XForms features takes place on the mailing list www-forms@w3.org.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Issue	Working Group Action	Commentor Position	Change Type	Notes
84: "This action has special deferred update behavior."	Accept	Agree	Editorial
74: [LC] 10.13 The prompt Action Element	Modify and Accept	Agree	Substantive	We removed the prompt element, which we do not believe will result in objections because the element was not implementable in the general case due to restrictions it had to make on event flow and UI content. The working group realized it could implement very similar functionality with no processing model hacks using group relevance, and deferred the ability to pop up a separate dialog with that functionality to a future release.
25: XForms value attribute	Defer	No Response	Substantive	Future version. See John's reply at: http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0044.html
51: XForms 1.1 LC comment on insert and delete	Defer	No Response	Editorial	Resolved June 15, 2007 to make better examples in XForms 1.1 and defer additional actions to XForms 1.2 (http://lists.w3.org/Archives/Public/public-forms/2007Jun/att-0041/20070615.html#ACTION7)
47: last call comments for Section 10	Modify and Accept	No Response	Substantive	Almost all editorial except our ultimate handling of #19 in the list. We removed the prompt element, which we do not believe will result in objections because the element was not implementable in the general case due to restrictions it had to make on event flow and UI content. The working group realized it could implement very similar functionality with no processing model hacks using group relevance, and deferred the ability to pop up a separate dialog with that functionality to a future release.
75: [LC: editorial] 9.3.6 The delete Action	Accept	Agree	Editorial
19: Specify meaning of setfocus to controls that will soon exist	Accept	Agree	Editorial
175: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing	Modify and Accept	No Response	Editorial	See reply.
31: XForms 1.1 comment - sample code error	Accept	No Response	Editorial
105: xf:insert and attribute order	Accept	No Response	Editorial
27: <setvalue/> XPath evaluation context improvements	Modify and Accept	No Response	Substantive	Not substantive in the "potentially objectionable" sense, just that we added a function that didn't exist before to solve the problem.
172: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing	Accept	No Response	Editorial
122: example "G.1 XForms in XHTML"	Accept	No Response	Editorial	We will simplify
128: CDF06 - 13 Glossary of Terms missing compound document.	Accept	No Response	Editorial
120: example "G.3 Survey Using XForms and SVG	Accept	No Response	Editorial	It should have been "latte" anyway (it's Italian not French)
106: Add scripts to XForms input-mode script list in Appendix E	Defer	None	N/A	This issue is deferred because the information is informative, so it can be added after the CR transition. There is no reason to hold up advancement while waiting for this non-normative information. This is a duplicate of issue PR #14 (and a few others) Suggest replacing list by reference to specs. Waiting for MD's opinion, and hopefully text. Martin replied: http://lists.w3.org/Archives/Public/www-forms-editor/2007Jun/0065 <<<< This may make sense to some extent, but it's not totally clear that all future additions to the Unicode list of scripts can be just added to the list of input mode tags in XForms. It is certainly not the case that the current list of scripts in Unicode is identical with the (currently proposed, incl. below) list of tags in XForms. Also, because there are changes in spelling, I think it's much more useful for implementers and users to have a full list. What I could immagine is that we add a sentence saying something like "it is expected that future versions of this specification will include tokens for scripts added to Unicode wherever that makes sense". >>>>
121: E.3.1 Script Tokens	Accept	Agree	N/A	Yes, we are doing this in collaboration with M Duerst. This is a duplicate of 106.
49: Last Call Comment: XForms 1.1 refers normatively to XForms 1.0 requirements but not XForms 1.1 requirements	Modify and Accept	Agree	Editorial
90: xforms:select and blank value	Accept	Agree	Editorial	Erik agrees with the resolution and helped produce the spec-ready text. RESOLUTION: Select items with blanks or empty values do not affect the storage value and these items should not be selectable by the user. ACTION: Erik Bruchez Erik to add text for select items with blanks or empty values do not affect the storage value and these items should not be selectable by the user (and have definition or better wording for blank).
89: More on xforms:select storage	Accept	Agree	Editorial	Erik agrees with the resolution and helped produce the spec-ready text. RESOLUTION: issue 89 we propose that the behavior be non-destructive and choose option 2a ACTION: Erik add text for issue 89 we propose that the behavior be non-destructive and choose option 2a.
117: Section 8	Accept	No Response	Editorial
88: xforms:select storage	Accept	Agree	Editorial	Erik agrees with the resolution and helped produce the spec-ready text. Proposed resolution for issue 88: We agree that the control present an out-of-range condition in this scenario, and to rewrite the paragraph to clarify that behavior. ACTION: Erik Clarify pargraph about out ouf range state on select Nick Van den Bleeken: not sure i like append. can't correct bad data any more.
72: [LC] 8.1.5 The output Element (+)	Accept	No Response	Substantive	The group agrees: all controls should be default inline, and all MIP properties should be perceivable on attached controls without interaction This change is modestly substantive in that it does describe more behavior for the UI controls than was described before. However, the risk of objection is quite low as it is describing agree upon styling defaults where previously form authors would have to always specify a value in order to achieve interoperability. Hence, no functionality is lost if they maintain that specificity, and it is easy to implement the defaults across implementations.
73: [LC] 8.3.2 The mediatype Element	Modify and Accept	No Response	Substantive	Modified to just add value as an optional attribute to mediatype element in output. This is only modestly substantive in the sense that we added an attribute, but not substantive in the sense we do not expect any objections to the addition.
30: Two descriptions of the output element	Accept	No Response	Editorial
18: LC: Clarify expectation of deleted-nodes property of xforms-delete	Modify and Accept	Agree	Substantive	Need to remove notion of half-detached nodes. Would like to determine the parents of deleted nodes, but there is no reasonable way to do this. This is only modestly substantive in that we removed a point feature that presented major anticipated implementation problems and that was not generalizable in the language anyway. We do not expect objections to its removal.
36: LC: xforms-compute-exception and xforms-binding-exception	Accept	Agree	N/A	Accepted, but deferred
50: Value changes upon instance replacement	Defer	Agree	N/A	JB: Initiallly I agreed, but now that I attempt to make some spec-ready text, it is not so clear. For better or worse, xforms-value-changed indicates that the value of the bound node has changed, not that the bound node itself has changed. I tried to modify Bullet point 2 so that it could include instance replacement as another means for changing a UI control's value. But unfortunately, xforms-value-changed does not track UI control value changes; it tracks data value changes. So, the problem resulted that my spec change caused it to be the case that if one form control changed its node binding to point to a new node, then other controls which were not changed at all would also receive xforms-value-changed. This is starting to feel more like a feature request for XForms 1.2. It might be possible to put in enough band-aid hacks to make XForms 1.1 do what is desired here, but we seem to need a different feature here because value-changed, like all the other events, is associated with a model item property (the value), and not with specific controls. It seems like we need something like an xforms-control-state event with context info that provides the value and state of all MIPs for the bound node. This could be dispatched on startup as well as any time something changes (the node binding, the value of the node binding, or a MIP). Maybe a completely different design is needed, but trying to bend xforms-value-changed to suit this use case looks problematic because, for better or worse, it doesn't appear to have been designed to accommodate it.
115: Section 4	Modify and Accept	No Response	Editorial	WG decided that all are editorial except 15 and 16, which I will move to separate issues. Modify and accept because responses to 20 and 21 do not make changes as this material in 4.7.1 and 4.7.2 is not intended to be read without also reading the preamble in 4.7. Adding text to 4.7.1 to clarify amounted to repeating the preamble.
57: [LC: editorial] 4.1 Events Overview	Accept	No Response	Editorial
155: Section 9	Accept	No Response	Editorial	The editor's draft contains spec-ready text for this in 4.3.2.
95: [LC] 4.3.6 The xforms-recalculate Event	Accept	Agree	Editorial
108: XForms 1.1 Last Call: comment about 4.4.5 The xforms-insert Event	Modify and Accept	Agree	Editorial	Final resolution was actually to remove the binding property altogether since it can only be used as a hack. Erik participated in the final discussion, which is whya second reply was not sent.
29: LC: Initial sending of MIP events	Defer	Agree	N/A	JB: This should be deferred for consideration as a future feature because the working group had valid reasons for not dispatching these events on initialization (and also not on instance replacement, if memory serves). The WG did not want xforms-invalid being dispatched on startup because it anticipated form authors wanting to hook xforms-invalid and present a message action (or ephemeral message). The solution to the problem might involve eventually deprecating message as an action, but it is too soon to tell. However, it is agreed that there are other use cases where even having xforms-invalid fire on startup can be useful, such as creating a list of all incorrect things on a form when it starts up. But this is a more sophisticated use case than a simple message, so it appears to be a feature request.
96: [LC] 4.5.5 The xforms-version-exception Event	Accept	Agree	Editorial
60: [LC] 4.4.21 The xforms-output-error Event	Accept	No Response	Editorial	Need better words to say that error happens on first attempt to render given data and another error happens if data changes or bound node changes.
61: [LC: Editorial] 4.5.5 The xforms-version-exception Event	Accept	Agree	Editorial	Steven was present for WG discussion where this was accepted, so no reply was sent. Use wording from description in the model element of @version
59: [LC: editorial] 4.4.20 The xforms-submit-error Event	Accept	Agree	Editorial	Steven was present for WG discussion where this was accepted, so no reply was sent. Move 4.4.20 (and 4.4.21) to Section 4.5
102: [LC] 6.1.3 The required Property	Accept	No Response	Editorial
176: Fw: when and how readonly MIP prevents data mutations	Modify and Accept	Agree	Substantive	With difficulty, the working group decided that readonly is an inviolate property of the model indicating that nothing is allowed to change the content nor attribute axis of a node whose readonly MIP is true.
82: Structural schema validation and datatype validation of first text node	Modify and Accept	Agree	Substantive	This issue is only substantive in the sense that it documents a change of implementation practice that was necessitated by the untenability of the prior 'first text node' approach, as documented in the notes below. We do not expect an objection as this change was made in response not only to this LC comment but numerous community implementation reports of difficulties with the prior approach. For part 1, the spec currently says in revalidate (section 4) that validation of all instance data occurs, not just datatype node, so we don't believe the spec implies that structural validation never occurs. For part 2, you identified a disconnect between schema validation and the first text node choice made by UI controls (8.1.1) and setvalue action (section 10). But the real problem is the choice made in UI controls and setvalue, both of which should just bind to the content of the referenced node. UI controls already having data binding exception if not bound to simpletype content, and setvalue should produce the same exception. Examples: <b></b> has no first text node child in xpath data model <b>1<!-- -->A</b> would show '1' to the user but be schema invalid as integer content In short, the UI bindings should bind to the content of the referenced node, not its first text node child for consistency.
100: 6.1 Model Item Property Definitions	Accept	No Response	Editorial
99: 6.1 Model Item Property Definitions	Defer	No Response	N/A
101: [LC: editorial] 6.1.2 The readonly Property	Modify and Accept	No Response	Editorial
45: Last call comment about readonly property with calculate	Modify and Accept	Disagree	Editorial
53: [LC] General remarks: Attributes	Accept	No Response	Editorial
119: ITS Rule file	Defer	No Response	None
171: Fw: Add optional root element to schema to encourage SoC	Reject	No Response	None	We will not add a root element to our schema. One can simply define one's own envelope element in any namespace except ours, and that element becomes a mini-host language.
125: CDF02 - Abstract (moved to Introduction) missing reference to compound documents.	Modify and Accept	Agree	Editorial	Initial response said "1) This is only a working draft whose advancement we don't want to be tied to; and 2) XForms is intended to be used with host languages even if they do not observe the compound document framework." The CDF group responded that they only wanted an informative reference to CDRF because it contained the definition of compound document, so the reference was added.
126: CDF03 - Abstract (Moved to Introduction) missing reference to ODF.	Modify and Accept	No Response	Editorial	We agreed to add ODF as example and to add an informative reference.
9: [XForms 1.1] i18n comment: Mention of Internationalization	Defer	No Response	N/A
162: [LC1.1] Changes from XForms 1.0 and examples	Accept	No Response	Editorial	We agreed to add a section to 1. About the XForms Specification
17: Formal Objection: publication of XForms 1.1 as LCWD	Modify and Accept	Agree	None	The changes needed were already made in XForms 1.0, which were carried forward to XForms 1.1. The objection is based on the fact that we didn't reply to earlier issues. We have now done that, see threads at: http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0050 http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0055 http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0056 No reply from the commentator. For the record, we don't believe the process allows a formal objection to a decision to go to last call. It would have been friendlier if the commentator had just said "please be sure to deal with the following issues".
15: [XForms 1.1] i18n comment: Various comments on XForms 1.1	Accept	No Response	Editorial	This is a duplicate of issues 109 (which was trashed in favour of separate issues). Recommend the following response: Answers for all last call comments attributed to Yves Savourel are now available in the www-forms-editor list archive and the results of spec changes now appear in the editor's draft available from the Forms WG website.
38: Upcoming RFC for Human Readable Resource Identifiers	Defer	Agree	N/A
113: Section 2	Accept	No Response	Editorial
35: XForms 1.1 comments: miscellaneous typos	Accept	No Response	Editorial
124: XForms 1.1 WD last call comments from CDFCDF01 - Abstract text moved to Introduction WG	Reject	Agree	None	The abstract of a document is supposed to be a miniature introduction to the document's content that helps a person decide whether or not they want to read the rest of the document. The XForms 1.0 abstract was inadequate to this purpose. It is clear that the document is a specification for XForms, but the abstract cannot end there. It must explain, basically, what XForms is. The abstract then explains the relationship between XForms 1.1 and 1.0, which is also necessary. For an example of a similar abstract, please see XPath 2.0.
94: [LC: Editorial]	Accept	No Response	Editorial	3.3.4 The bind Element
86: More on datatype validation: what's a possible algorithm?	Accept	Agree	None	There is an 'accept' with no edits here because we basically agreed not to do some work that had not already been done.
13: [XForms 1.1] i18n comment: Responsibility for useability of IRIs unclear	Defer	Agree	N/A	Felix Sasaki accepted this resolution because we had already indicated clearly that we fully support xsd:anyURI, which implies broad support for IRIs anyway, despite some edge case exceptionalities.
93: [LC] 3.3.2 The instance Element	Reject	Agree	None
28: LC: Problems with Binding Expressions changing evaluation context of other attributes	Defer	Agree	N/A
114: Section 3	Modify and Accept	No Response	Editorial	Editorial fixes, most of which were accepted. Non-accepted are not technical (e.g. the version of XHTML we cite).
112: 1) MustUnderstand	Accept	No Response	Editorial	Another last call comment also requested removal of this optional module because it is not widely implemented as an optional module; the reason, in turn, is that it appears to be a CDF problem, not something that can be solved by XForms alone.
56: [LC] 3.2.1 Common Attributes	Accept	Agree	Editorial
8: [XForms 1.1] i18n comment: IRIs for external schema locations possible?	Defer	Agree	N/A
58: [LC] 3.3.2 The instance Element	Accept	No Response	Editorial
55: [LC] 3.2.2 Linking Attributes	Accept	Agree	Substantive	This is only a modestly substantive change w.r.t. the last call document. XForms has always supported src, and we tried one way of expressing that more clearly in LC; we now express it much more clearly by adopting it into XForms from the host language. This reflects how implementers are actually processing it, and it satifies this LC comment, and it helped to resolve the I18N group's issue with whether or not we support all of xsd:anyURI (which could not be stated definitively while src remained a host language construct). So we do not expect any objection to this change.
2: Question regarding TestCase 3.4.1.a and mustUnderstand	Accept	No Response	Editorial	Group has agreed to remove mustunderstand. This was an optional module that was not widely implemented because it is a CDF problem, not something that can be solved in XForms.
87: Strict and lax schema validation	Modify and Accept	Agree	Editorial	Leigh and Erik to document current practice, which is that strict is used if there are any top-level element or attribute declarations in a namespace, lax otherwise (e.g. if only type libs are applicable to the namespace). Perhaps special case for no namespace instances where temp variables often live. John's old comments: This is actually a pretty nasty problem for us. On the one hand, I think the only real answer here is strict. XML schema defines strict as the default, and you can only go to lax or skip if the schema defines processContents to override strictness OR a schema validator may switch to lax mode once a strict failure has happened due to not having a matching element declaration (or an association of type via xsi:type). On the other hand, we cannot report as invalid an instance whose only failing is that there were no matching element and attribute declarations. To work around this problem, and also to optimize, I believe we only apply a schema to an instance if the root element has a namespace that matches the schema target namespace. The major downside here is that raw data in a SOAP envelope tends not to get schema validated.
129: XForms 1.1 WD last call comments from CDF WG	Accept	No Response	Editorial	We have resolved to remove mustunderstand. Two other last call comments also requested removal of this optional module because it is not widely implemented as an optional module; the reason, in turn, is that it appears to be a CDF problem, not something that can be solved by XForms alone.
154: Section 9	Accept	No Response	Substantive	Another LC comment (#55) also requested this. This is only a modestly substantive change w.r.t. the last call document. XForms has always supported src, and we tried one way of expressing that more clearly in LC; we now express it much more clearly by adopting it into XForms from the host language. This reflects how implementers are actually processing it, and it satifies this LC comment, and it helped to resolve the I18N group's issue with whether or not we support all of xsd:anyURI (which could not be stated definitively while src remained a host language construct). So we do not expect any objection to this change.
104: XForms document versioning	Modify and Accept	No Response	Substantive	This is only modestly substantive in that it changed how version worked. We do not expect an objection since the same description appears in XForms 1.0 Third Edition, which was accepted as a Recommendation.
85: xsi:type	Accept	Agree	Editorial
127: CDF04 - 3.3 The XForms Core Module missing reference to compound document profile.	Accept	No Response	Editorial
91: Re: XForms 1.1 spec editor's drafts now available on public page	Accept	No Response	Editorial
76: [LC] 11.1 The submission Element	Modify and Accept	Agree	Substantive	The changes are mostly editorial. The substantive change was the change of name of the 'verb' element to 'method'. As explained in another LC comment, and also evident here, the name 'verb' was confusing and we were unable to find a current normative reference for that name, so the same features were renamed 'method'. No objection is expected due to the increase of clarity and because the name change does not invalidate any prior experience implementing the feature under the old name. Detailed notes: 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. 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. 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. 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. 5) All of the optional attributes of submission now have their default values or behaviors specified.
103: [LC1.1] Section 11.7 'verb'	Accept	No Response	Substantive	Mostly editorial changes. The substantive change was the change of name of the 'verb' element to 'method'. As explained in three other LC comments, and also evident here, the name 'verb' was confusing and we were unable to find a current normative reference for that name, so the same features were renamed 'method'. No objection is expected due to the increase of clarity and because the name change does not invalidate any prior experience implementing the feature under the old name. Detailed notes: 1) Eliminated verb in favor of better use of method attr/elem pair. 2) Based on elimination of verb in favor of method attr/elem, we also switched to having a serialization attr, whose default is determined by the method. This allowed us to clean up the table substantially. 3) Verb is eliminated. As in XForms 1.0, the method setting would be post or urlencoded-post, both of which would result in an HTTP method (as defined in RFC 2616) of POST. For the HTTP scheme, the method is what we were referring to as the "verb". What we meant there was the protocol operation, which under the HTTP protocol is the "method". 4) Now that we have switched to using 'method', it is clear that there is no default. 5) The element has been renamed 'method', but error reported here is fixed.
83: Required but empty	Reject	Agree	None	Rejected because the definition of empty string is clear and has to be the same as is defined in XML Schema for validation purposes and in XPath for calculation processing purposes.
163: [LC1.1] Changes from XForms 1.0 and examples	Accept	No Response	Editorial	We add examples for: replace all, replace instance, replace none, replace text, xforms-submit-done, xforms-submit-error, xforms-submit, xforms-submit-serialize, dynamic URL in the resource section, and file load/save.
81: [LC] 11.9 Submission Options	Modify and Accept	Agree	Editorial	The verb element/attribute pair was eliminated in favor of expanding on the 'method'. Since method is required to specify, there is no longer confusion about the default verb (by which we meant submission protocol operation, which under the http protocol is in fact called the method). The ability to control the "verb" now rests with the 'method', so in the table in 11.9 there is no longer an ambiguity about how the http method/protocol verb/protocol operation is obtained. Please see the newly titled column "Submission Protocol Operation" and in particular the value for the row for "Any other NCName".
4: [LC1.1] 11.8 The header Element	Accept	No Response	Substantive	We will relax the order. This is modestly substantive in that it changes the schema, but we do not expect objection since it relaxes the order of required child elements to ease authoring. Since all child elements were required to implement, no implementation experience currently garnered could be invalidated by this change.
78: [LC] 11.7 Submission verb Attribute and Element	Modify and Accept	Agree	Substantive	The substantive change was the change of name of the 'verb' element to 'method'. As explained in two other LC comments, and also evident here, the name 'verb' was confusing and we were unable to find a current normative reference for that name, so the same features were renamed 'method'. No objection is expected due to the increase of clarity and because the name change does not invalidate any prior experience implementing the feature under the old name. Detailed notes: The verb elem/attr pair were eliminated. The method element was added as a way to provide an XPath expr in lieu of the literal value in the method attr, which is a pre-existing literal-valued attr. The method element also allows literal expression, which may still be seen as 'overkill' but it was done for consistency, i.e. in other places in XForms literal content can be provided in places where the value attr can also appear.
54: 1.1 resource element comment	Accept	No Response	Editorial
1: Re: XForms 1.1: Submit event (11.2) - @serialize	Accept	Agree	Substantive	We accepted the new defaults for relevant and validate; we changed the XForms submit event default processing. This is modestly substantive in that it changes behavior, but we do not expect objection since it changes defaults to the most sensible values. Since all default and non-default cases were required to implement, no implementation experience currently garnered could be invalidated by this change.
46: last call comments for section 11	Accept	No Response	Substantive	Most of the changes were editorial, but in one case we changed the name of an element from verb to method because we could find no current normative references for the prior name ('verb') and it was that name which caused the confusion. We expect no objections since the name change simply clarifies what is going on and could not invalidate implementation experience garnered thus far with implementing the feature under the old name.
80: [LC] 11.8 The header Element	Reject	No Response	None	The main reason is that the WG felt that XPath-based name and value attributes made it too difficult for the case of specifying a literal, which is easier to understand when you recognize that the nodeset attribute is optional. Basically, the header element was created and then nodeset was added to simplify getting a large block of headers from instance data. So the question might then become, why can't we add name and value as literal attributes at least. Two reasons. First, this variant is not useful when nodeset is used. Second, when there is no nodeset, it does indeed seem less verbose to specify a header with attributes. The problem we encountered there was that the value attribute would then be a literal string, which is inconsistent with its datatype of XPathExpr everywhere else in XForms. And if we make it an XPath, then again we would be in the trap of authors having frustration when they forget to put the extra quotes needed to express a string literal in an XPath. So, in this case, the WG felt it was best to have only the child elements name and value, both of which offer a literal content version and a value attribute for specifying an XPath.
77: [LC] 11.6 The resource Element and Attribute	Modify and Accept	Agree	Editorial	We did not make resource into an XPath because this would be inconsistent with how resource is used on instance and on load. Uniformly, resource is an xsd:anyURI. It wouldn't be overkill if @action were deprecated, which is perhaps what was not clear enough. I think we should modify/accept this by making it clearer that we want to deprecate @action. The reason above for deprecating action is so that we consistently use the name resource, but there is a second reason too. The name 'action' for the attribute is constantly confusing in explanations of submission because one must distinguish between action, the URI, and action, the handler of xforms-submit-done. By deprecating @action, there would no longer be a name conflict.
79: [LC: editorial] 11.2 The xforms-submit Event	Accept	No Response	Editorial
10: [XForms 1.1] i18n comment: Restriction of international mail addresses unclear	Defer	No Response	N/A
136: Section 5.1	Accept	No Response	Editorial
138: Section 5.2.7	Accept	No Response	Editorial	Essentially duplicate of issue types/22. We are rewriting the paragrqaph to take away the confusion.
6: [XForms 1.1] i18n comment: Lexical space for XForms data types missing	Accept	No Response	Editorial	Prior notes were incorrect. Section 8.1.1 is using the terms correctly. Section 5 has to mention that lex space is what goes into and comes out of the data, and that the datatype descriptions in section 5 are generally lex space descriptions.
48: XML Core WG review of XForms 1.1	Modify and Accept	No Response	Editorial
137: Section 5.2.3	Reject	No Response	None	RESOLUTION: Stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
98: [LC] 5.2.5 xforms:email and 5.2.6 xforms:ID-card-number	Accept	Agree	Substantive	This only barely substantive because it implies a schema change, but we expect no objections because these two new datatypes are expected to behave consistently with all other xforms datatypes, which have been painstakingly added to allow a user to start out with an empty document that does not complain of validity errors on start up. That a node must be non-empty by the end of the form fill experience is uniformly handled by the 'required' MIP. Note this also applies to listItem listItems dayTimeDuration and yearMonthDuration
7: [XForms 1.1] i18n comment: Reference to definition of data types missing	Reject	No Response	None	RESOLUTION : We stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
135: 1.0 errata section 10 (complex type validation clarification)	Accept	No Response	Editorial
92: Nillable complex type with simple content	Accept	Agree	Editorial	We clarified in the spec that nillable is not applicable to the type MIP because schema associates it with element validity, not type validity.
97: [LC: Editorial] 5.2.5 xforms:email	Accept	Agree	Editorial	Proposed changes (by nvdbleek): Add the following example to the "Examples of invalid xforms:email addresses" mailto:editors@example.com Add the following note mailto:editors@example.com is a valid xsd:anyURI but is not valid xforms:email
22: Fw: Confusion on datatypes with empty content	Accept	No Response	Editorial
62: [LC] 5.2 XForms Datatypes	Accept	No Response	Editorial
21: LC: Issues with repeat index manipulation and generalized insert/delete actions	Modify and Accept	Agree	Substantive	This is only substantive in that it describes semantic changes that affect the meaning of elements related to repeat index management. However, we do not expect objections as this change is necessary to make repeat index management work correctly in all cases and to achieve the WG objective of generalizing insert/delete, which includes removing behaviors not related to data mutation from insert/delete. Current implementations of 1.0 are making index mgmt work in most or all cases using strategies similar or identical to those now described, so the prior text was inadequate at reflecting best practice. Detailed notes: The working group resolved to accept this LC comment, assigning Action 2007-08-15.3 to John. The working group further resolved that the solution must accommodate the content of http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html
3: removal of the notion of a homogeneous collection from XForms 1.1 WD	Accept	Agree	Substantive	This is substantive in that it changes behavior of the nodeset binding of repeat, but we expect no objection as the WG is unanimously in favor of this and indeed most implementers of 1.0 do not observe the homogeneous collection limitation (which 1.0 left 'undefined' to allow implementers to try it out). This changes is also consisten with the generalizations made to insert and delete actions.
24: LC: Issue with repeat index and rebuild	Modify and Accept	Agree	Editorial	John was in the room and agreed with the defer of automatically detecting when to flag a rebuild on repeat index change. Subsequent work to rigorously define "dynamic dependency" have substantially clarified exactly what kind of dependencies are created by index() invocations. Invocation in a model expression does not cause a rebuild. However, all changes of index, including ones caused by focus change, set the recalculate etc. flags. Also invocations of index() create a dependency to implicit instance data representing the repeat index, so setindex is like a setvalue. This makes it crystal clear that index() used in a UI binding is supposed to be dynamically updated, but index() used in a model binding or compute does not signal a rebuild.
118: Section 9	Modify and Accept	No Response	Editorial	Some of the issues were mistakes on Aaron's part; others resulted in fixes.
23: LC: Legacy cruft in Section 9.3.8	Accept	Agree	Editorial
26: Request for an update for <repeat/> element.	Accept	No Response	Substantive	As explained in another LC comment, this is substantive in that it changes behavior of the nodeset binding of repeat, but we expect no objection as the WG is unanimously in favor of this and indeed most implementers of 1.0 do not observe the homogeneous collection limitation (which 1.0 left 'undefined' to allow implementers to try it out). This changes is also consisten with the generalizations made to insert and delete actions.
153: Section 9	Accept	No Response	Editorial	Spec ready solutions are now available for both of these issues in the editor's draft. 35) We clarified in a note that all template content (including actions) are made unavailable to the host language processor. So handlers declared within a repeat do not handle elements dispatched to the repeat (and likewise for itemset). Actions declared within a repeat template operate over the repeated content (e.g. the item elements generated by an itemset). 36) The actions within an itemset are applicable to each item generated. The sentence claiming that actions in the itemset don't handle events on the itemset has been changed to simply state that, as with repeat, handlers defined within itemset do not handle events on the itemset. This is necessary to prevent a double run of event handlers as events bubble up from generated content to the generating repeat or itemset. An example of how to handle events dispatched to a repeat or itemset was added.
143: 7.6	Defer	No Response	N/A	With regard to specific functions like boolean-from-string(), many were already defined by XForms 1.0 a very long time ago because, in XPath 1.0, the boolean() function does not do the right thing. With regard to the more general suggestion of putting our functions into the XForms namespace and then providing a way to switch to that namespace as the default, unfortunately we do not believe this is implementable with XPath 1.0 evaluators. Therefore the working group defers putting its functions into the XForms namespace until XForms 2.0 when we expect XPath 2.0 to be adopted.
107: Comments on XPath 2.0 features	Defer	No Response	None
71: [LC: editorial] 7.11.3 The choose() Function	Modify and Accept	Agree	Editorial	See reply.
149: 7.11.4	Defer	No Response	None	The working group decided to add the two parameter id() function, call it id(), and make its semantics as close to XPath 2.0 as possible. Any semantic differences remaining will need to be addressed in XForms 2.0 when we migrate to XPath 2.0.
65: [LC: editorial] 7.10.1 The now() Function	Accept	Agree	Editorial	Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63 Steven was in the room and agreed.
41: Things wrong with section "7.5 Binding Expressions" and related	Accept	Agree	Editorial
69: [LC] 7.10.6 The local-date() Function and 7.10.7 The local-dateTime() Function	Accept	Disagree	Editorial	RESOLUTION: Clarify and add examples to show that now() returns Z time only and add examples of local-dateTime() that connect it to now() return results Examples, OK. The difference is basically whether or not the returned value is just the local date or date/time or whether it is corrected from the local value to the UTC value (which is what now() does). An example showing late in the day pacific time returning early the next day UTC from now() should suffice.
68: [LC] 7.9.4 The digest() Function	Modify and Accept	No Response	Substantive	This is only substantive in the sense that there are fewer keywords available for the parameters, but all possible features are still accessible by the reduced number of keywords. 1)drop alternatives of lower case keywords (e.g.: drop sha-256, SHA256, SHA-256 variants of sha256) 2) editorial correct function names in samples process together with XPath/67
146: 7.9.3	Modify and Accept	No Response	Substantive	This is a substantive change for which we do not anticipate an objection because the functions were technically unimplementable (as described below) and because they were only exposed because they seemed like they might be useful utilities that would be available based on parts of functionality needed by digest() and hmac(). No requirements go unsatisfied by their removal. RESOLUTION: We will shoot both decode and encode because : 1) XPath can't store control characters in a string http://www.w3.org/TR/xpath#strings 2) encode and decode work on bytes in other languages ( most of the people will expect that encode(decode(<data>)) returns the same string, but this is not the case because control characters aren't allowed, and if we use the 32-bit string characters the string will double, going through UTF-8 also modifies the binary data
140: 7.1	Defer	No Response	N/A	This one says "Why not XPath 2.0 now in 1.1" which we already decided not to do until probably XForms 2.0 due to the huge ramifications on dependency calculations of things like XPath 2.0's 'if' But we did deprecate "if" and we removed the return type rationalization for choose(), so we have taken steps to smooth the way for XPath 2.0.
40: Typo in 7.6 The XForms Function Library	Accept	Agree	Editorial
139: Section 7	Accept	Agree	Editorial	ACTION: Erik to address this with expanded wording about failure on undefined variable references and function calls.
148: 7.11.1	Accept	No Response	Editorial
177: Fw: Comment about location of choose() and event() functions in the spec	Accept	Agree	Editorial
63: [LC] 5.2.6 xforms:ID-card-number and 7.8.7 The luhn() Function	Modify and Accept	Agree	Substantive	The resolution was card-number for the type and is-card-number() for the function. This is only substantive in the sense that the names were changed, which does not invalidate prior implementation experiences with the features.
44: Last call comment: XForms 1.1 is missing a string compare capability	Accept	Agree	Substantive	This is substantive in that it adds a function, but we do not expect an objection since it adds a function commensurate with the two parameter version of the same function appearing in XPath 2.0, which is a recommendation. This is part of our long term shift toward XPath 2.0.
144: Comments 7.7.2	Modify and Accept	No Response	Substantive	This is barely substantive in that we removed a subtle semantic on the choose() function to align it with the decision structure available in XPath 2.0. Detailed notes: We have deprecated if(). It is still supported, but authors and design tool creators have been encouraged to change over to using choose(). We also removed return type rationalization from choose() to make it more compatible with the XPath 2.0 if construct. Adoption of Xpath 2.0 is likely to correspond to XForms 2.0. As a major version change to the language, it will be safe for us to drop support for if() in that version. We expect to also have an XForms 1.2, and we will likely have to leave if() as supported but deprecated in that language version too.
11: [XForms 1.1] i18n comment: Require UTC as default for time zone information	Accept	Agree	Editorial	Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63
142: 7.5.1	Accept	No Response	Editorial	An expression is dependent upon a node or function return result if a change to the node or function return result causes a change to the expression result. The set of dependents for an expression is called its dependency list. An expression is dynamically dependent on a node or function return result if a change to the node or function return result causes a change to the dependency list of the expression. The master dependency graph of the model is not automatically rebuilt in all cases in which a model binding expression's dependency list changes. The insert and delete actions set the rebuild flag, so data mutations such as inserting or deleting element and attribute nodes do correspond to a rebuild. However, if a model expression's dependency list is changed based on a change to a text value is changed by a form control or setvalue action, a rebuild is not automatically performed. Similarly, changes that affect the return results of functions like id(), index() and now() do not automatically result in a rebuild. An implementation does not forbid the use of dynamic dependencies in model binding expressions, however, form authors are encouraged to use them only when the rebuild action can be manually triggered to correspond account for the change of dependency list. Perhaps "restriction" is not the right word. I think "limitation" is the right word.
33: LC: Sections 7.2 and 7.3 should be in their own section	Accept	No Response	Editorial	These have been moved to the end of section 4 in the editor's draft.
70: [LC] 7.10.8 The seconds() Function	Accept	No Response	Editorial	Reply: seconds("P1Y2M") returns 0 and not NaN because the input is a valid duration but the seconds function doesn't takes months and years into account. However we will switch the first and second example so that the first example returns a not zero value.
12: [XForms 1.1] i18n comment: Availability of time zone information unclear	Reject	Agree	None	Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63
39: Typo in 7.5.3 UI Binding Expressions	Accept	Agree	Editorial
152: Re: id function and xsi:type	Accept	Agree	Editorial
141: 7.4	Defer	No Response	N/A	Evaluation context section (now 7.2) is very precisely tailored to our needs based on XPath 1.0, which we must use for XForms 1.1. It also accounts for content repetition that XForms performs, which is why the section contains more information than what might be described for the evaluation context of a single XPath expression. There is nothing specific to accept or reject here, but we have not made any changes to section 7.4 based on this comment.
147: 7.10.4	Modify and Accept	Disagree	Editorial	This is a several-years-old XForms 1.0 function defined for use with XPath 1.0. The semantic differences should probably be addressed in XForms 2.0 when we actually move to XPath 2.0. Regarding leap seconds, I would guess the answer is no, and such should be said both in this function and in seconds-to-dateTime().
161: editorial: 7.11.1 The instance() Function	Accept	No Response	Editorial	Elliotte's email identified a section number and problem common to XForms 1.1 and 1.0. I replied that the problem was already fixed here: http://lists.w3.org/Archives/Public/www-forms-editor/2007Jul/0011.html He clarifies that he meant to report the problem on 1.0 here: http://lists.w3.org/Archives/Public/www-forms-editor/2007Jul/0012.html
66: [LC] 7.8.8 The random() Function	Accept	No Response	Editorial	we need the specify the interval of random
34: LC: Minor consistency issue: "halt" vs. "stop"	Accept	Agree	Editorial	It is just an editorial change
156: Section 7: hasFeature	Reject	No Response	None	I think there is confusion about what hasFeature() is. I do not think it is a function callable from XPath. As Mark B rightly pointed out, section 7.2 is in the wrong chapter, and it has been moved to the end of Chapter 4 in the editor's draft. I believe the return value should still be 1.0 because this appears to be the first version of the DOM interface.
67: [LC] 7.9.5 The hmac() Function	Accept	No Response	Substantive	drop alternatives of lower case keywords (e.g.: drop sha-256, SHA256, SHA-256 variants of sha256) Only modestly substantive; no implementation experience or review is invalidated by dropping the keywords as all the possible hash algorithms are still represented
64: [LC: editorial] 7.8.6 The power() Function	Accept	No Response	Editorial	Add example: power(2, 3) Returns 8
145: 7.8.8	Reject	Disagree	None
116: Section 7	Accept	No Response	Editorial	These were all deemed editorial. However, 22 is not so it has been moved to a separate issue.

1. Actions

1.1 "This action has special deferred update behavior."

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree

1.2 [LC] 10.13 The prompt Action Element

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree

1.3 XForms value attribute

1.4 XForms 1.1 LC comment on insert and delete

STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Defer
USER POSITION: No Response

1.5 last call comments for Section 10

STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response

1.6 [LC: editorial] 9.3.6 The delete Action