Copyright ©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This note outlines the way in which the XForms Working Group has addressed comments received to date against working drafts of XForms 1.1
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.
This document has been produced as part of the W3C Forms Activity. The goals of the Forms Working Group (members only) are discussed in the Forms Working Group charter (members only).
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. |
PROBLEM ID: 84
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> A minor comment on the wording "This action has special deferred update behavior." I am wondering what's so "special" about it - that is, besides the fact that it is subject to deferred update behavior. The wording suggests to me that not only are these actions subject to deferred update behavior, but that somehow there is something particularly unusual going on, which is not the case. I would just say that "This action is subject to deferred update behavior.". -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Erik, we agree. The referenced sections will be changed. Regards, Ulrich Nicolas Lissé. For the Forms WG > A minor comment on the wording "This action has special deferred update > behavior." > > I am wondering what's so "special" about it - that is, besides the fact > that it is subject to deferred update behavior. The wording suggests to > me that not only are these actions subject to deferred update behavior, > but that somehow there is something particularly unusual going on, which > is not the case. > > I would just say that "This action is subject to deferred update > behavior.". > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 74
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#action-prompt Why isn't <message> sufficient for this?
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Steven, message is not suffcient for this usecase. However, we decided to remove the prompt action from XForms 1.1 since it creates more problems than it solves. Regards, Ulrich Nicolas Lissé. For the Forms WG > http://www.w3.org/TR/xforms11/#action-prompt > > Why isn't <message> sufficient for this? > >
PROBLEM ID: 25
STATE: Suspended
EDIT: Substantive
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
Future version. See John's reply at: http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0044.html
ORIGINAL MESSAGE:
From: "Andrew Bonard" <Andrew.Bonard@harlandfs.com> Hello, I'd like to suggest that we have a value attribute that can be used on the send element in section 10.11. The optional attribute would contain an XPath expression to evaluate using the in-scope evaluation context. The result of the XPath expression is the submission identity. The markup might look something like: <action> <send value="concat('submission_', ../defaultSendLocation)"/> </action> My feeling is that the attribute would allow for a more dynamic and configurable binding to the submission element. Regards, Andrew Bonard
PROBLEM ID: 51
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
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)
ORIGINAL MESSAGE:
From: "Mark Birbeck" <mark.birbeck@x-port.net> Although incredibly powerful, I feel that the latest versions of insert and delete are just too complicated for use in day-to-day form building. I find that I am constantly forced to look at examples in the spec or our tutorials, especially when dealing with attributes. And worse, if looking at mark-up from other authors, I find it takes a while to work out what it is that some code is doing. The core of the problem is the way that the attributes behave when used in combination, which often requires reference to documentation to be completely sure that you've got it right. I have no immediate suggestions as to how to resolve this, but I would say that in general it is easier to code if there are a number of actions that do something small and specific, rather than one action that does a lot. So, for example, copying a node from one instance to another is probably easier to understand if the action is called 'copy' or 'duplicate'. The fact that an 'insertion' takes place seems secondary, and it's even possible that a node will be overwritten rather than inserted. Regards, Mark -- Mark Birbeck, formsPlayer mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Mark, we agree. We are about to create new descriptive example tables for insert and delete using one set of instance data. In general, nodeset is used when you want to pick one of the children of a node and insert before or after that node, and context is used when you want to append or prepend a child inside a node. In future versions of XForms we may add more dedicated actions which are essentially shortcuts to insert/delete. Regards, Ulrich Nicolas Lissé. For the Forms WG > Although incredibly powerful, I feel that the latest versions of > insert and delete are just too complicated for use in day-to-day form > building. I find that I am constantly forced to look at examples in > the spec or our tutorials, especially when dealing with attributes. > And worse, if looking at mark-up from other authors, I find it takes a > while to work out what it is that some code is doing. > > The core of the problem is the way that the attributes behave when > used in combination, which often requires reference to documentation > to be completely sure that you've got it right. > > I have no immediate suggestions as to how to resolve this, but I would > say that in general it is easier to code if there are a number of > actions that do something small and specific, rather than one action > that does a lot. So, for example, copying a node from one instance to > another is probably easier to understand if the action is called > 'copy' or 'duplicate'. The fact that an 'insertion' takes place seems > secondary, and it's even possible that a node will be overwritten > rather than inserted. > > Regards, > > Mark > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > >
PROBLEM ID: 47
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 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!!! /\
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> 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!!! > /\ > >
PROBLEM ID: 75
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#action-delete The last line but one has an extra double quote in the example on nodeset="item""/>
FOLLOWUP 1:
From: John Boyer <xforms-issues@aptest.com> Hi John, Yes you are correct. I had attempted to account for the absence of a statement about insertion or deletion when the insertion or deletion location node is the root node (the parent of the root element node), but I see now thanks to your feedback that combining that step with the material for the root element of an instance introduces a problem. So, the changes made to the latest editor's draft do swap the steps as you requested (see steps c and d) while also retaining a modified step b that only addresses the root node. Regarding the question you asked about the phrase "or the child list if the insert location node is empty" appearing now in part 6c, this phrase explains how to obtain the target location when the insert location node is empty. In that case, the target location is the child list of the insert location node. It is much easier to see that this is true by looking at the non-diff-marked version. Finally, note that the section on insert now appears in Chapter 10 with all the other actions. Please let us know if you find any other issues with insert and delete as your review of these sections is invaluable. Thank you, John Boyer > This is a multipart message in MIME format. > --=_alternative 001A595788257331_= > Content-Type: text/plain; charset="US-ASCII" > > "Clark, John" <CLARKJ2@ccf.org> > Sent by: www-forms-editor-request@w3.org > 08/06/2007 06:29 AM > > To > www-forms-editor@w3.org > cc > > Subject > RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 > processing (PR#172) > > > > > > > >> Hi John, >> Yes, it was an omission of the spec, and insertion into an >> empty node was intended. >> >> The latest editor's draft available from the Forms WG home >> page contains a correction. Please see the diff-marked >> version. Also, please note that step 6 received other >> modifications due to addressing other last call comments, so >> the fix needed to address your specific issue is at the end >> of step 6c. Please let us know if you have any further >> concerns about this issue. > > Could you please explain what the phrase "or the child list if the > 'insert location node' is empty" means? What is the "child list"? What > does it mean to insert a node before the child list of another node? > > Also, as I read the latest diff-marked version of section 9.3.5[0], I am > concerned that it is impossible to insert a (non-attribute) node as a > child of an element that has no children and is the root element of an > instance. > > Consider the "Append new person" trigger in the first example in that > section. In this example, when this trigger first receives the > DOMActivate event the "insert context" is `instance('people')`, the Node > Set Binding node-set is the empty node-set, the "origin node-set" is > `instance('personProto')`, and the "insert location node" is > `instance('people')`. Now, to determine the "target location", we use > rule 6. Subrule "a." does not apply, since the cloned node is an > element. Moving to subrule "b.", since the "insert location node" is > the root element of the 'people' instance, the root element of the > 'people' instance becomes the "target location". Thus, in rule 7, since > the "target location" is "the root element of an instance, then the > cloned node replaces the instance root element." I don't think this was > the intent of that example. > > I believe that swapping subrules "b." and "c." would solve this problem. > > [0] > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in > sert > > Take care, > > John L. Clark > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 001A595788257331_= > Content-Type: text/html; charset="US-ASCII" > > > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into > an empty element (section  9.3.5 processing (PR#172)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > > Hi John,<br> > > Yes, it was an omission of the spec, and insertion into an <br> > > empty node was intended.<br> > > <br> > > The latest editor's draft available from the Forms WG home <br> > > page contains a correction.  Please see the diff-marked <br> > > version.  Also, please note that step 6 received other <br> > > modifications due to addressing other last call comments, so <br> > > the fix needed to address your specific issue is at the end <br> > > of step 6c.  Please let us know if you have any further <br> > > concerns about this issue.<br> > <br> > Could you please explain what the phrase "or the child list if the<br> > 'insert location node' is empty" means?  What is the "child > list"?  What<br> > does it mean to insert a node before the child list of another node?<br> > <br> > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br> > concerned that it is impossible to insert a (non-attribute) node as a<br> > child of an element that has no children and is the root element of an<br> > instance.<br> > <br> > Consider the "Append new person" trigger in the first example > in that<br> > section.  In this example, when this trigger first receives the<br> > DOMActivate event the "insert context" is `instance('people')`, > the Node<br> > Set Binding node-set is the empty node-set, the "origin node-set" > is<br> > `instance('personProto')`, and the "insert location node" is<br> > `instance('people')`.  Now, to determine the "target location", > we use<br> > rule 6.  Subrule "a." does not apply, since the cloned node > is an<br> > element.  Moving to subrule "b.", since the "insert > location node" is<br> > the root element of the 'people' instance, the root element of the<br> > 'people' instance becomes the "target location".  Thus, > in rule 7, since<br> > the "target location" is "the root element of an instance, > then the<br> > cloned node replaces the instance root element."  I don't think > this was<br> > the intent of that example.<br> > <br> > I believe that swapping subrules "b." and "c." would > solve this problem.<br> > <br> > [0]<br> > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font > size=2><br> > sert<br> > <br> > Take care,<br> > <br> >   John L. Clark<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 001A595788257331_=-- > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, This has been fixed. Please see the editor's draft available from the Forms WG website. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#action-delete > > The last line but one has an extra double quote in the example on > nodeset="item""/> > > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi John, Yes you are correct. I had attempted to account for the absence of a statement about insertion or deletion when the insertion or deletion location node is the root node (the parent of the root element node), but I see now thanks to your feedback that combining that step with the material for the root element of an instance introduces a problem. So, the changes made to the latest editor's draft do swap the steps as you requested (see steps c and d) while also retaining a modified step b that only addresses the root node. Regarding the question you asked about the phrase "or the child list if the insert location node is empty" appearing now in part 6c, this phrase explains how to obtain the target location when the insert location node is empty. In that case, the target location is the child list of the insert location node. It is much easier to see that this is true by looking at the non-diff-marked version. Finally, note that the section on insert now appears in Chapter 10 with all the other actions. Please let us know if you find any other issues with insert and delete as your review of these sections is invaluable. Thank you, John Boyer > This is a multipart message in MIME format. > --=_alternative 001A595788257331_= > Content-Type: text/plain; charset="US-ASCII" > > "Clark, John" <CLARKJ2@ccf.org> > Sent by: www-forms-editor-request@w3.org > 08/06/2007 06:29 AM > > To > www-forms-editor@w3.org > cc > > Subject > RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 > processing (PR#172) > > > > > > > >> Hi John, >> Yes, it was an omission of the spec, and insertion into an >> empty node was intended. >> >> The latest editor's draft available from the Forms WG home >> page contains a correction. Please see the diff-marked >> version. Also, please note that step 6 received other >> modifications due to addressing other last call comments, so >> the fix needed to address your specific issue is at the end >> of step 6c. Please let us know if you have any further >> concerns about this issue. > > Could you please explain what the phrase "or the child list if the > 'insert location node' is empty" means? What is the "child list"? What > does it mean to insert a node before the child list of another node? > > Also, as I read the latest diff-marked version of section 9.3.5[0], I am > concerned that it is impossible to insert a (non-attribute) node as a > child of an element that has no children and is the root element of an > instance. > > Consider the "Append new person" trigger in the first example in that > section. In this example, when this trigger first receives the > DOMActivate event the "insert context" is `instance('people')`, the Node > Set Binding node-set is the empty node-set, the "origin node-set" is > `instance('personProto')`, and the "insert location node" is > `instance('people')`. Now, to determine the "target location", we use > rule 6. Subrule "a." does not apply, since the cloned node is an > element. Moving to subrule "b.", since the "insert location node" is > the root element of the 'people' instance, the root element of the > 'people' instance becomes the "target location". Thus, in rule 7, since > the "target location" is "the root element of an instance, then the > cloned node replaces the instance root element." I don't think this was > the intent of that example. > > I believe that swapping subrules "b." and "c." would solve this problem. > > [0] > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in > sert > > Take care, > > John L. Clark > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 001A595788257331_= > Content-Type: text/html; charset="US-ASCII" > > > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into > an empty element (section  9.3.5 processing (PR#172)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > > Hi John,<br> > > Yes, it was an omission of the spec, and insertion into an <br> > > empty node was intended.<br> > > <br> > > The latest editor's draft available from the Forms WG home <br> > > page contains a correction.  Please see the diff-marked <br> > > version.  Also, please note that step 6 received other <br> > > modifications due to addressing other last call comments, so <br> > > the fix needed to address your specific issue is at the end <br> > > of step 6c.  Please let us know if you have any further <br> > > concerns about this issue.<br> > <br> > Could you please explain what the phrase "or the child list if the<br> > 'insert location node' is empty" means?  What is the "child > list"?  What<br> > does it mean to insert a node before the child list of another node?<br> > <br> > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br> > concerned that it is impossible to insert a (non-attribute) node as a<br> > child of an element that has no children and is the root element of an<br> > instance.<br> > <br> > Consider the "Append new person" trigger in the first example > in that<br> > section.  In this example, when this trigger first receives the<br> > DOMActivate event the "insert context" is `instance('people')`, > the Node<br> > Set Binding node-set is the empty node-set, the "origin node-set" > is<br> > `instance('personProto')`, and the "insert location node" is<br> > `instance('people')`.  Now, to determine the "target location", > we use<br> > rule 6.  Subrule "a." does not apply, since the cloned node > is an<br> > element.  Moving to subrule "b.", since the "insert > location node" is<br> > the root element of the 'people' instance, the root element of the<br> > 'people' instance becomes the "target location".  Thus, > in rule 7, since<br> > the "target location" is "the root element of an instance, > then the<br> > cloned node replaces the instance root element."  I don't think > this was<br> > the intent of that example.<br> > <br> > I believe that swapping subrules "b." and "c." would > solve this problem.<br> > <br> > [0]<br> > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font > size=2><br> > sert<br> > <br> > Take care,<br> > <br> >   John L. Clark<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 001A595788257331_=-- > >
PROBLEM ID: 19
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> It is supposed to be the case that you can setfocus to a control that is within a repeat, like this: <trigger> <label>Send me to I2</label> <setfocus ev:event="DOMActivate" control="I2"/> </trigger> <repeat id="R" nodeset="a/b/c"> <input id="I1" ...> ...</input> <input id="I2" ...> ...</input> </repeat> But the specification does not say what happens when the focus is sent to I2 on a newly created repeat item: <trigger> <label>Send me to I2</label> <action ev:event="DOMActivate" > <insert nodeset="a/b/c" ... /> <setfocus control="I2"/> </action> </trigger> I believe that the focus should still arrive on I2 in the newly created set of UI controls, but this is because I believe that setfocus has a deferred behavior that is imposed at the end of xforms-refresh. This deferred behavior is not specified, so I wonder what other implementations are doing. Either way, clearly the above markup (the second trigger) should not fail to set the focus, but a literal reading of the current spec would seem to imply that it does because the repeat index of R is increased as soon as the insert occurs, yet the corresponding controls do not exist until the next xforms-refresh. John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> John, thank you for pointing this out. The proposed resolution is: The setfocus, toggle, and setindex actions will run the actions indicated by the deferred-update flags (which will clear the flags). Regards, Ulrich Nicolas Lissé. For the Forms WG > It is supposed to be the case that you can setfocus to a control that is > within a repeat, like this: > > <trigger> > <label>Send me to I2</label> > <setfocus ev:event="DOMActivate" control="I2"/> > </trigger> > > <repeat id="R" nodeset="a/b/c"> > <input id="I1" ...> ...</input> > <input id="I2" ...> ...</input> > </repeat> > > But the specification does not say what happens when the focus is sent to > I2 on a newly created repeat item: > > <trigger> > <label>Send me to I2</label> > <action ev:event="DOMActivate" > > <insert nodeset="a/b/c" ... /> > <setfocus control="I2"/> > </action> > </trigger> > > I believe that the focus should still arrive on I2 in the newly created > set of UI controls, but this is because I believe that setfocus has a > deferred behavior that is imposed at the end of xforms-refresh. > > This deferred behavior is not specified, so I wonder what other > implementations are doing. Either way, clearly the above markup (the > second trigger) should not fail to set the focus, but a literal reading of > the current spec would seem to imply that it does because the repeat index > of R is increased as soon as the insert occurs, yet the corresponding > controls do not exist until the next xforms-refresh. > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 175
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
See reply.
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 001A595788257331_= Content-Type: text/plain; charset="US-ASCII" "Clark, John" <CLARKJ2@ccf.org> Sent by: www-forms-editor-request@w3.org 08/06/2007 06:29 AM To www-forms-editor@w3.org cc Subject RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing (PR#172) > Hi John, > Yes, it was an omission of the spec, and insertion into an > empty node was intended. > > The latest editor's draft available from the Forms WG home > page contains a correction. Please see the diff-marked > version. Also, please note that step 6 received other > modifications due to addressing other last call comments, so > the fix needed to address your specific issue is at the end > of step 6c. Please let us know if you have any further > concerns about this issue. Could you please explain what the phrase "or the child list if the 'insert location node' is empty" means? What is the "child list"? What does it mean to insert a node before the child list of another node? Also, as I read the latest diff-marked version of section 9.3.5[0], I am concerned that it is impossible to insert a (non-attribute) node as a child of an element that has no children and is the root element of an instance. Consider the "Append new person" trigger in the first example in that section. In this example, when this trigger first receives the DOMActivate event the "insert context" is `instance('people')`, the Node Set Binding node-set is the empty node-set, the "origin node-set" is `instance('personProto')`, and the "insert location node" is `instance('people')`. Now, to determine the "target location", we use rule 6. Subrule "a." does not apply, since the cloned node is an element. Moving to subrule "b.", since the "insert location node" is the root element of the 'people' instance, the root element of the 'people' instance becomes the "target location". Thus, in rule 7, since the "target location" is "the root element of an instance, then the cloned node replaces the instance root element." I don't think this was the intent of that example. I believe that swapping subrules "b." and "c." would solve this problem. [0] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in sert Take care, John L. Clark =================================== Cleveland Clinic is ranked one of the top hospitals in America by U.S. News & World Report (2007). Visit us online at http://www.clevelandclinic.org for a complete listing of our services, staff and locations. Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you. --=_alternative 001A595788257331_= Content-Type: text/html; charset="US-ASCII" <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" <CLARKJ2@ccf.org></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 processing (PR#172)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> > Hi John,<br> > Yes, it was an omission of the spec, and insertion into an <br> > empty node was intended.<br> > <br> > The latest editor's draft available from the Forms WG home <br> > page contains a correction. Please see the diff-marked <br> > version. Also, please note that step 6 received other <br> > modifications due to addressing other last call comments, so <br> > the fix needed to address your specific issue is at the end <br> > of step 6c. Please let us know if you have any further <br> > concerns about this issue.<br> <br> Could you please explain what the phrase "or the child list if the<br> 'insert location node' is empty" means? What is the "child list"? What<br> does it mean to insert a node before the child list of another node?<br> <br> Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br> concerned that it is impossible to insert a (non-attribute) node as a<br> child of an element that has no children and is the root element of an<br> instance.<br> <br> Consider the "Append new person" trigger in the first example in that<br> section. In this example, when this trigger first receives the<br> DOMActivate event the "insert context" is `instance('people')`, the Node<br> Set Binding node-set is the empty node-set, the "origin node-set" is<br> `instance('personProto')`, and the "insert location node" is<br> `instance('people')`. Now, to determine the "target location", we use<br> rule 6. Subrule "a." does not apply, since the cloned node is an<br> element. Moving to subrule "b.", since the "insert location node" is<br> the root element of the 'people' instance, the root element of the<br> 'people' instance becomes the "target location". Thus, in rule 7, since<br> the "target location" is "the root element of an instance, then the<br> cloned node replaces the instance root element." I don't think this was<br> the intent of that example.<br> <br> I believe that swapping subrules "b." and "c." would solve this problem.<br> <br> [0]<br> </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font size=2><br> sert<br> <br> Take care,<br> <br> John L. Clark<br> <br> ===================================<br> <br> Cleveland Clinic is ranked one of the top hospitals<br> in America by U.S. News & World Report (2007). <br> Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> for<br> a complete listing of our services, staff and<br> locations.<br> <br> <br> Confidentiality Note: This message is intended for use<br> only by the individual or entity to which it is addressed<br> and may contain information that is privileged,<br> confidential, and exempt from disclosure under applicable<br> law. If the reader of this message is not the intended<br> recipient or the employee or agent responsible for<br> delivering the message to the intended recipient, you are<br> hereby notified that any dissemination, distribution or<br> copying of this communication is strictly prohibited. If<br> you have received this communication in error, please<br> contact the sender immediately and destroy the material in<br> its entirety, whether electronic or hard copy. Thank you.<br> <br> <br> <br> <br> </font></tt> --=_alternative 001A595788257331_=--
FOLLOWUP 1:
From: John Boyer <xforms-issues@aptest.com> Hi John, Yes you are correct. I had attempted to account for the absence of a statement about insertion or deletion when the insertion or deletion location node is the root node (the parent of the root element node), but I see now thanks to your feedback that combining that step with the material for the root element of an instance introduces a problem. So, the changes made to the latest editor's draft do swap the steps as you requested (see steps c and d) while also retaining a modified step b that only addresses the root node. Regarding the question you asked about the phrase "or the child list if the insert location node is empty" appearing now in part 6c, this phrase explains how to obtain the target location when the insert location node is empty. In that case, the target location is the child list of the insert location node. It is much easier to see that this is true by looking at the non-diff-marked version. Finally, note that the section on insert now appears in Chapter 10 with all the other actions. Please let us know if you find any other issues with insert and delete as your review of these sections is invaluable. Thank you, John Boyer > This is a multipart message in MIME format. > --=_alternative 001A595788257331_= > Content-Type: text/plain; charset="US-ASCII" > > "Clark, John" <CLARKJ2@ccf.org> > Sent by: www-forms-editor-request@w3.org > 08/06/2007 06:29 AM > > To > www-forms-editor@w3.org > cc > > Subject > RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 > processing (PR#172) > > > > > > > >> Hi John, >> Yes, it was an omission of the spec, and insertion into an >> empty node was intended. >> >> The latest editor's draft available from the Forms WG home >> page contains a correction. Please see the diff-marked >> version. Also, please note that step 6 received other >> modifications due to addressing other last call comments, so >> the fix needed to address your specific issue is at the end >> of step 6c. Please let us know if you have any further >> concerns about this issue. > > Could you please explain what the phrase "or the child list if the > 'insert location node' is empty" means? What is the "child list"? What > does it mean to insert a node before the child list of another node? > > Also, as I read the latest diff-marked version of section 9.3.5[0], I am > concerned that it is impossible to insert a (non-attribute) node as a > child of an element that has no children and is the root element of an > instance. > > Consider the "Append new person" trigger in the first example in that > section. In this example, when this trigger first receives the > DOMActivate event the "insert context" is `instance('people')`, the Node > Set Binding node-set is the empty node-set, the "origin node-set" is > `instance('personProto')`, and the "insert location node" is > `instance('people')`. Now, to determine the "target location", we use > rule 6. Subrule "a." does not apply, since the cloned node is an > element. Moving to subrule "b.", since the "insert location node" is > the root element of the 'people' instance, the root element of the > 'people' instance becomes the "target location". Thus, in rule 7, since > the "target location" is "the root element of an instance, then the > cloned node replaces the instance root element." I don't think this was > the intent of that example. > > I believe that swapping subrules "b." and "c." would solve this problem. > > [0] > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in > sert > > Take care, > > John L. Clark > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 001A595788257331_= > Content-Type: text/html; charset="US-ASCII" > > > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into > an empty element (section  9.3.5 processing (PR#172)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > > Hi John,<br> > > Yes, it was an omission of the spec, and insertion into an <br> > > empty node was intended.<br> > > <br> > > The latest editor's draft available from the Forms WG home <br> > > page contains a correction.  Please see the diff-marked <br> > > version.  Also, please note that step 6 received other <br> > > modifications due to addressing other last call comments, so <br> > > the fix needed to address your specific issue is at the end <br> > > of step 6c.  Please let us know if you have any further <br> > > concerns about this issue.<br> > <br> > Could you please explain what the phrase "or the child list if the<br> > 'insert location node' is empty" means?  What is the "child > list"?  What<br> > does it mean to insert a node before the child list of another node?<br> > <br> > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br> > concerned that it is impossible to insert a (non-attribute) node as a<br> > child of an element that has no children and is the root element of an<br> > instance.<br> > <br> > Consider the "Append new person" trigger in the first example > in that<br> > section.  In this example, when this trigger first receives the<br> > DOMActivate event the "insert context" is `instance('people')`, > the Node<br> > Set Binding node-set is the empty node-set, the "origin node-set" > is<br> > `instance('personProto')`, and the "insert location node" is<br> > `instance('people')`.  Now, to determine the "target location", > we use<br> > rule 6.  Subrule "a." does not apply, since the cloned node > is an<br> > element.  Moving to subrule "b.", since the "insert > location node" is<br> > the root element of the 'people' instance, the root element of the<br> > 'people' instance becomes the "target location".  Thus, > in rule 7, since<br> > the "target location" is "the root element of an instance, > then the<br> > cloned node replaces the instance root element."  I don't think > this was<br> > the intent of that example.<br> > <br> > I believe that swapping subrules "b." and "c." would > solve this problem.<br> > <br> > [0]<br> > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font > size=2><br> > sert<br> > <br> > Take care,<br> > <br> >   John L. Clark<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 001A595788257331_=-- > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi John, Yes you are correct. I had attempted to account for the absence of a statement about insertion or deletion when the insertion or deletion location node is the root node (the parent of the root element node), but I see now thanks to your feedback that combining that step with the material for the root element of an instance introduces a problem. So, the changes made to the latest editor's draft do swap the steps as you requested (see steps c and d) while also retaining a modified step b that only addresses the root node. Regarding the question you asked about the phrase "or the child list if the insert location node is empty" appearing now in part 6c, this phrase explains how to obtain the target location when the insert location node is empty. In that case, the target location is the child list of the insert location node. It is much easier to see that this is true by looking at the non-diff-marked version. Finally, note that the section on insert now appears in Chapter 10 with all the other actions. Please let us know if you find any other issues with insert and delete as your review of these sections is invaluable. Thank you, John Boyer > This is a multipart message in MIME format. > --=_alternative 001A595788257331_= > Content-Type: text/plain; charset="US-ASCII" > > "Clark, John" <CLARKJ2@ccf.org> > Sent by: www-forms-editor-request@w3.org > 08/06/2007 06:29 AM > > To > www-forms-editor@w3.org > cc > > Subject > RE: Fw: [XForms 1.1] Inserting into an empty element (section 9.3.5 > processing (PR#172) > > > > > > > >> Hi John, >> Yes, it was an omission of the spec, and insertion into an >> empty node was intended. >> >> The latest editor's draft available from the Forms WG home >> page contains a correction. Please see the diff-marked >> version. Also, please note that step 6 received other >> modifications due to addressing other last call comments, so >> the fix needed to address your specific issue is at the end >> of step 6c. Please let us know if you have any further >> concerns about this issue. > > Could you please explain what the phrase "or the child list if the > 'insert location node' is empty" means? What is the "child list"? What > does it mean to insert a node before the child list of another node? > > Also, as I read the latest diff-marked version of section 9.3.5[0], I am > concerned that it is impossible to insert a (non-attribute) node as a > child of an element that has no children and is the root element of an > instance. > > Consider the "Append new person" trigger in the first example in that > section. In this example, when this trigger first receives the > DOMActivate event the "insert context" is `instance('people')`, the Node > Set Binding node-set is the empty node-set, the "origin node-set" is > `instance('personProto')`, and the "insert location node" is > `instance('people')`. Now, to determine the "target location", we use > rule 6. Subrule "a." does not apply, since the cloned node is an > element. Moving to subrule "b.", since the "insert location node" is > the root element of the 'people' instance, the root element of the > 'people' instance becomes the "target location". Thus, in rule 7, since > the "target location" is "the root element of an instance, then the > cloned node replaces the instance root element." I don't think this was > the intent of that example. > > I believe that swapping subrules "b." and "c." would solve this problem. > > [0] > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in > sert > > Take care, > > John L. Clark > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 001A595788257331_= > Content-Type: text/html; charset="US-ASCII" > > > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">08/06/2007 06:29 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">RE: Fw: [XForms 1.1] Inserting into > an empty element (section  9.3.5 processing (PR#172)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > > Hi John,<br> > > Yes, it was an omission of the spec, and insertion into an <br> > > empty node was intended.<br> > > <br> > > The latest editor's draft available from the Forms WG home <br> > > page contains a correction.  Please see the diff-marked <br> > > version.  Also, please note that step 6 received other <br> > > modifications due to addressing other last call comments, so <br> > > the fix needed to address your specific issue is at the end <br> > > of step 6c.  Please let us know if you have any further <br> > > concerns about this issue.<br> > <br> > Could you please explain what the phrase "or the child list if the<br> > 'insert location node' is empty" means?  What is the "child > list"?  What<br> > does it mean to insert a node before the child list of another node?<br> > <br> > Also, as I read the latest diff-marked version of section 9.3.5[0], I am<br> > concerned that it is impossible to insert a (non-attribute) node as a<br> > child of an element that has no children and is the root element of an<br> > instance.<br> > <br> > Consider the "Append new person" trigger in the first example > in that<br> > section.  In this example, when this trigger first receives the<br> > DOMActivate event the "insert context" is `instance('people')`, > the Node<br> > Set Binding node-set is the empty node-set, the "origin node-set" > is<br> > `instance('personProto')`, and the "insert location node" is<br> > `instance('people')`.  Now, to determine the "target location", > we use<br> > rule 6.  Subrule "a." does not apply, since the cloned node > is an<br> > element.  Moving to subrule "b.", since the "insert > location node" is<br> > the root element of the 'people' instance, the root element of the<br> > 'people' instance becomes the "target location".  Thus, > in rule 7, since<br> > the "target location" is "the root element of an instance, > then the<br> > cloned node replaces the instance root element."  I don't think > this was<br> > the intent of that example.<br> > <br> > I believe that swapping subrules "b." and "c." would > solve this problem.<br> > <br> > [0]<br> > </font></tt><a href="http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in"><tt><font > size=2>http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#action-in</font></tt></a><tt><font > size=2><br> > sert<br> > <br> > Take care,<br> > <br> >   John L. Clark<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 001A595788257331_=-- > >
PROBLEM ID: 31
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Gary F Stevens" <gfsteven@us.ibm.com> In section 10.14 of the specification there is an error in the provided sample code Handling Focus for Empty Repeats. The second trigger control does not have an ending tag of </trigger>, but instead the tag </input>. Gary F Stevens gfsteven@us.ibm.com Software Group - Emerging Standards IBM/US/Raleigh-RTP
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Gary, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > > > > In section 10.14 of the specification there is an error in the provided > sample code Handling Focus for Empty Repeats. The second trigger control > does not have an ending tag of </trigger>, but instead the tag </input>. > > Gary F Stevens > gfsteven@us.ibm.com > Software Group - Emerging Standards > IBM/US/Raleigh-RTP > >
PROBLEM ID: 105
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "paul butcher" <paul.butcher@formsplayer.com> In the Working Draft of 22 February 2007, Items 6a and 6b in section 9.3.5, "The insert Action" (http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert) both state that " If the cloned node is an attribute, then the target location is before the first attribute of the insert location node node." Given the following, this directive is meaningless: According to XML, "the order of attribute specifications in a start-tag or empty-element tag is not significant." http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags According to XML Infoset, the attributes property of the element information item is "An unordered set of attribute information items, one for each of the attributes" http://www.w3.org/TR/xml-infoset/#infoitem.element Also, according to the DOM, one cannot insert attributes at a given location with insertBefore, appendChild, or replaceChild. Therefore, the only way to achieve the mandated effect would be to remove each of the attributes, then set them again in the correct order. However, given the above, I'm not sure that would be reliable. http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1590626202 and http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-952280727 -- Paul Butcher, formsPlayer paul.butcher@x-port.net www.formsPlayer.com standards. innovation.
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Paul, we changed 6a and 6b to say that the insert location is the attribute list of the insert location node's parent element. Regards, Ulrich Nicolas Lissé. For the Form WG > In the Working Draft of 22 February 2007, Items 6a and 6b in section > 9.3.5, "The insert Action" > (http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert) both > state that " If the cloned node is an attribute, then the target > location is before the first attribute of the insert location node > node." Given the following, this directive is meaningless: > > According to XML, > "the order of attribute specifications in a start-tag or empty-element > tag is not significant." > http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags > > According to XML Infoset, the attributes property of the element > information item is "An unordered set of attribute information items, > one for each of the attributes" > http://www.w3.org/TR/xml-infoset/#infoitem.element > > Also, according to the DOM, one cannot insert attributes at a given > location with insertBefore, appendChild, or replaceChild. Therefore, > the only way to achieve the mandated effect would be to remove each of > the attributes, then set them again in the correct order. However, > given the above, I'm not sure that would be reliable. > > http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1590626202 > > and > http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-952280727 > > > -- > Paul Butcher, formsPlayer > paul.butcher@x-port.net > www.formsPlayer.com standards. innovation. > > >
PROBLEM ID: 27
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
Not substantive in the "potentially objectionable" sense, just that we added a function that didn't exist before to solve the problem.
ORIGINAL MESSAGE:
From: "Ivan Latysh" <IvanLatysh@yahoo.ca> Hello all, I want to propose a change to XForm spec regarding <setvalue/> "value" attribute evaluation context. Currently spec force setvalue element to use target node context: [copy] "The evaluation context for this XPath expression is the result from the Single Node Binding." [/copy] When in fact it should honour current scope and be consistent with other XForms elements. I propose to update <setvalue/> "value" definition with: [copy] value Optional XPath expression to evaluate, with the result stored in the selected instance data node. The evaluation context for this XPath expression described in 7.4 Evaluation Context. [/copy] Here is the real-world use-case that will work after the change: <xf:model id="myModel"> <xf:instance id="myInstance" xmlns=""> <root> <fruit>apple</fruit> <fruit>orange</fruit> <fruit>mandarine</fruit> <fruit>tomato</fruit> <bad-fruit>Unknown</bad-fruit> </root> </xf:instance> </xf:model> <xf:repeat nodeset="instance('myInstance')/fruit" model="myModel" id="fruits-repeat"> <xf:trigger> <xf:label>Pick</xf:label> <xf:action ev:event="DOMActivate"> <xf:setvalue ref="instance('myInstance')/bad-fruit" value="."/> </xf:action> </xf:trigger> </xf:repeat> Taking into the consideration that such change may cause certain issues with existing forms John M. Boyer propose to add a flag that will govern XForm behaviour: [John M. Boyer] I couldn't say what to name it, but maybe another attribute on the default model would do the trick. Something like unifiedcontext= "true|false". The true setting would say that all attributes of an element are evaluated with the in-scope evaluation context (i.e. the result of @context, if it appears, or the default otherwise). The true setting could even be the default for 1.1, and the false setting could be the default for 1.0 forms. [John M. Boyer] Also I belive that we can add the "version" attribute to <html/> tag. For example: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xf:version="1.1"> -- Best regards, Ivan mailto:IvanLatysh@yahoo.ca
FOLLOWUP 1:
From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com> This is a MIME-encapsulated message --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 13 Jun 2007 08:27:03 -0500 from htmlwg.mn.aptest.com [127.0.0.1] ----- Transcript of session follows ----- <IvanLatysh@yahoo.ca>... Deferred Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com Content-Type: message/delivery-status Reporting-MTA: dns; htmlwg.mn.aptest.com Arrival-Date: Wed, 13 Jun 2007 08:27:03 -0500 Final-Recipient: RFC822; IvanLatysh@yahoo.ca Action: delayed Status: 4.4.2 Last-Attempt-Date: Wed, 13 Jun 2007 12:44:28 -0500 Will-Retry-Until: Mon, 18 Jun 2007 08:27:03 -0500 --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com Content-Type: message/rfc822 Return-Path: <xforms-issues@mn.aptest.com> Received: from localhost (htmlwg.mn.aptest.com [127.0.0.1]) by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id l5DDR3tX001710 for <IvanLatysh@yahoo.ca>; Wed, 13 Jun 2007 08:27:03 -0500 Date: Wed, 13 Jun 2007 08:27:03 -0500 Message-Id: <200706131327.l5DDR3tX001710@htmlwg.mn.aptest.com> From: xforms-issues@mn.aptest.com To: IvanLatysh@yahoo.ca Subject: Re: <setvalue/> XPath evaluation context improvements (PR#27) X-Loop: xforms-issues@mn.aptest.com Your issue has been added to the W3C's Forms Working Group Issue Tracking System. If you have further information about this issue to report, please reply to this message so that the additional data can be automatically attached to the original query. If you would like to check on the status of this issue, select the following link: http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues?findid=27 This link will take you to a page that shows your issue and its status. If you would like to check on the other issues in the system, you can do so via the web at http://htmlwg.mn.aptest.com/xforms-issues --l5DHSOcp003364.1181756668/htmlwg.mn.aptest.com--
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Ivan, thanks for reporting this. To solve this issue we decided to add a context() function to return the in-scope evaluation context for the element containing the attribute containing the xpath expression. Regards, Ulrich Nicolas Lissé. For the Forms WG > Hello all, > > I want to propose a change to XForm spec regarding <setvalue/> "value" > attribute evaluation context. > Currently spec force setvalue element to use target node context: > [copy] > "The evaluation context for this XPath expression is the result from > the Single Node Binding." > [/copy] > When in fact it should honour current scope and be consistent with other > XForms elements. > > I propose to update <setvalue/> "value" definition with: > [copy] > value > Optional XPath expression to evaluate, with the result stored in the > selected instance data node. > The evaluation context for this XPath expression described in 7.4 > Evaluation Context. > [/copy] > > Here is the real-world use-case that will work after the change: > <xf:model id="myModel"> > <xf:instance id="myInstance" xmlns=""> > <root> > <fruit>apple</fruit> > <fruit>orange</fruit> > <fruit>mandarine</fruit> > <fruit>tomato</fruit> > <bad-fruit>Unknown</bad-fruit> > </root> > </xf:instance> > </xf:model> > <xf:repeat nodeset="instance('myInstance')/fruit" model="myModel" > id="fruits-repeat"> > <xf:trigger> > <xf:label>Pick</xf:label> > <xf:action ev:event="DOMActivate"> > <xf:setvalue ref="instance('myInstance')/bad-fruit" value="."/> > </xf:action> > </xf:trigger> > </xf:repeat> > > Taking into the consideration that such change may cause certain issues > with existing forms John M. Boyer propose to > add a flag that will govern XForm behaviour: > [John M. Boyer] > I couldn't say what to name it, but maybe another attribute on the > default model would do the trick. Something like > unifiedcontext= "true|false". The true setting would say that all > attributes of an element are evaluated with the > in-scope evaluation context (i.e. the result of @context, if it appears, > or the default otherwise). The true setting > could even be the default for 1.1, and the false setting could be the > default for 1.0 forms. > [John M. Boyer] > > Also I belive that we can add the "version" attribute to <html/> tag. > For example: > <html xmlns="http://www.w3.org/1999/xhtml" > xmlns:xf="http://www.w3.org/2002/xforms" > xmlns:ev="http://www.w3.org/2001/xml-events" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" xf:version="1.1"> > > > -- > Best regards, > Ivan mailto:IvanLatysh@yahoo.ca > > >
PROBLEM ID: 172
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 006C3F4E88257329_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:42 PM ----- "Clark, John" <CLARKJ2@ccf.org> Sent by: www-forms-editor-request@w3.org 07/20/2007 07:15 AM To www-forms-editor@w3.org cc Subject [XForms 1.1] Inserting into an empty element (section 9.3.5 processing rule 6.a) As I read the latest working draft of the XForms specification[0], I am unsure what will happen at processing rule 6.a if the cloned node is not an attribute and the `insert location node` does not have any children. In this case, "the target location is before the first child of the insert location node", but that is not well-defined if there is no such first child. I think it would be a significant gap in the specification if the eventual language would not allow a node to be inserted into an empty element. Is there any chance that this could be clarified (hopefully in favor of being able to insert a node into an element with no children)? [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert Take care, John L. Clark | Systems Analyst | Cardio-Thoracic Surgery Research Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195 | (216) 445-6011 =================================== Cleveland Clinic is ranked one of the top hospitals in America by U.S. News & World Report (2007). Visit us online at http://www.clevelandclinic.org for a complete listing of our services, staff and locations. Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you. --=_alternative 006C3F4E88257329_= Content-Type: text/html; charset="US-ASCII" <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" <CLARKJ2@ccf.org></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty element (section 9.3.5 processing rule 6.a)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> As I read the latest working draft of the XForms specification[0], I am<br> unsure what will happen at processing rule 6.a if the cloned node is not<br> an attribute and the `insert location node` does not have any children.<br> In this case, "the target location is before the first child of the<br> insert location node", but that is not well-defined if there is no such<br> first child. I think it would be a significant gap in the specification<br> if the eventual language would not allow a node to be inserted into an<br> empty element.<br> <br> Is there any chance that this could be clarified (hopefully in favor of<br> being able to insert a node into an element with no children)?<br> <br> [0] </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font size=2><br> <br> Take care,<br> <br> John L. Clark | Systems Analyst<br> | Cardio-Thoracic Surgery Research<br> Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195<br> | (216) 445-6011<br> <br> ===================================<br> <br> Cleveland Clinic is ranked one of the top hospitals<br> in America by U.S. News & World Report (2007). <br> Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> for<br> a complete listing of our services, staff and<br> locations.<br> <br> <br> Confidentiality Note: This message is intended for use<br> only by the individual or entity to which it is addressed<br> and may contain information that is privileged,<br> confidential, and exempt from disclosure under applicable<br> law. If the reader of this message is not the intended<br> recipient or the employee or agent responsible for<br> delivering the message to the intended recipient, you are<br> hereby notified that any dissemination, distribution or<br> copying of this communication is strictly prohibited. If<br> you have received this communication in error, please<br> contact the sender immediately and destroy the material in<br> its entirety, whether electronic or hard copy. Thank you.<br> <br> <br> <br> <br> </font></tt> --=_alternative 006C3F4E88257329_=--
FOLLOWUP 1:
From: John Boyer <xforms-issues@aptest.com> Hi John, Yes, it was an omission of the spec, and insertion into an empty node was intended. The latest editor's draft available from the Forms WG home page contains a correction. Please see the diff-marked version. Also, please note that step 6 received other modifications due to addressing other last call comments, so the fix needed to address your specific issue is at the end of step 6c. Please let us know if you have any further concerns about this issue. Thanks, John Boyer > Subject > [XForms 1.1] Inserting into an empty element (section 9.3.5 processing > rule 6.a) > > As I read the latest working draft of the XForms specification[0], I am > unsure what will happen at processing rule 6.a if the cloned node is not > an attribute and the `insert location node` does not have any children. > In this case, "the target location is before the first child of the > insert location node", but that is not well-defined if there is no such > first child. I think it would be a significant gap in the specification > if the eventual language would not allow a node to be inserted into an > empty element. > > Is there any chance that this could be clarified (hopefully in favor of > being able to insert a node into an element with no children)? > > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert > > Take care, > > John L. Clark | Systems Analyst > | Cardio-Thoracic Surgery Research > Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195 > | (216) 445-6011 > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 006C3F4E88257329_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty > element (section 9.3.5  processing rule 6.a)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > As I read the latest working draft of the XForms specification[0], I am<br> > unsure what will happen at processing rule 6.a if the cloned node is not<br> > an attribute and the `insert location node` does not have any children.<br> > In this case, "the target location is before the first child of the<br> > insert location node", but that is not well-defined if there is no > such<br> > first child.  I think it would be a significant gap in the > specification<br> > if the eventual language would not allow a node to be inserted into an<br> > empty element.<br> > <br> > Is there any chance that this could be clarified (hopefully in favor of<br> > being able to insert a node into an element with no children)?<br> > <br> > [0] </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font > size=2><br> > <br> > Take care,<br> > <br> >   John L. Clark  |  Systems Analyst<br> >          | >  Cardio-Thoracic > Surgery Research<br> > Cleveland Clinic  |  9500 Euclid Ave.  |  Cleveland, > OH 44195<br> >          |  (216) > 445-6011<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 006C3F4E88257329_=-- > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi John, Yes, it was an omission of the spec, and insertion into an empty node was intended. The latest editor's draft available from the Forms WG home page contains a correction. Please see the diff-marked version. Also, please note that step 6 received other modifications due to addressing other last call comments, so the fix needed to address your specific issue is at the end of step 6c. Please let us know if you have any further concerns about this issue. Thanks, John Boyer > Subject > [XForms 1.1] Inserting into an empty element (section 9.3.5 processing > rule 6.a) > > As I read the latest working draft of the XForms specification[0], I am > unsure what will happen at processing rule 6.a if the cloned node is not > an attribute and the `insert location node` does not have any children. > In this case, "the target location is before the first child of the > insert location node", but that is not well-defined if there is no such > first child. I think it would be a significant gap in the specification > if the eventual language would not allow a node to be inserted into an > empty element. > > Is there any chance that this could be clarified (hopefully in favor of > being able to insert a node into an element with no children)? > > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert > > Take care, > > John L. Clark | Systems Analyst > | Cardio-Thoracic Surgery Research > Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195 > | (216) 445-6011 > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 006C3F4E88257329_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty > element (section 9.3.5  processing rule 6.a)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > As I read the latest working draft of the XForms specification[0], I am<br> > unsure what will happen at processing rule 6.a if the cloned node is not<br> > an attribute and the `insert location node` does not have any children.<br> > In this case, "the target location is before the first child of the<br> > insert location node", but that is not well-defined if there is no > such<br> > first child.  I think it would be a significant gap in the > specification<br> > if the eventual language would not allow a node to be inserted into an<br> > empty element.<br> > <br> > Is there any chance that this could be clarified (hopefully in favor of<br> > being able to insert a node into an element with no children)?<br> > <br> > [0] </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font > size=2><br> > <br> > Take care,<br> > <br> >   John L. Clark  |  Systems Analyst<br> >          | >  Cardio-Thoracic > Surgery Research<br> > Cleveland Clinic  |  9500 Euclid Ave.  |  Cleveland, > OH 44195<br> >          |  (216) > 445-6011<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 006C3F4E88257329_=-- > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi John, Yes, it was an omission of the spec, and insertion into an empty node was intended. The latest editor's draft available from the Forms WG home page contains a correction. Please see the diff-marked version. Also, please note that step 6 received other modifications due to addressing other last call comments, so the fix needed to address your specific issue is at the end of step 6c. Please let us know if you have any further concerns about this issue. Thanks, John Boyer > This is a multipart message in MIME format. > --=_alternative 006C3F4E88257329_= > Content-Type: text/plain; charset="US-ASCII" > > ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:42 PM ----- > > "Clark, John" <CLARKJ2@ccf.org> > Sent by: www-forms-editor-request@w3.org > 07/20/2007 07:15 AM > > To > www-forms-editor@w3.org > cc > > Subject > [XForms 1.1] Inserting into an empty element (section 9.3.5 processing > rule 6.a) > > > > > > > > As I read the latest working draft of the XForms specification[0], I am > unsure what will happen at processing rule 6.a if the cloned node is not > an attribute and the `insert location node` does not have any children. > In this case, "the target location is before the first child of the > insert location node", but that is not well-defined if there is no such > first child. I think it would be a significant gap in the specification > if the eventual language would not allow a node to be inserted into an > empty element. > > Is there any chance that this could be clarified (hopefully in favor of > being able to insert a node into an element with no children)? > > [0] http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert > > Take care, > > John L. Clark | Systems Analyst > | Cardio-Thoracic Surgery Research > Cleveland Clinic | 9500 Euclid Ave. | Cleveland, OH 44195 > | (216) 445-6011 > > =================================== > > Cleveland Clinic is ranked one of the top hospitals > in America by U.S. News & World Report (2007). > Visit us online at http://www.clevelandclinic.org for > a complete listing of our services, staff and > locations. > > > Confidentiality Note: This message is intended for use > only by the individual or entity to which it is addressed > and may contain information that is privileged, > confidential, and exempt from disclosure under applicable > law. If the reader of this message is not the intended > recipient or the employee or agent responsible for > delivering the message to the intended recipient, you are > hereby notified that any dissemination, distribution or > copying of this communication is strictly prohibited. If > you have received this communication in error, please > contact the sender immediately and destroy the material in > its entirety, whether electronic or hard copy. Thank you. > > > > > > --=_alternative 006C3F4E88257329_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 07/31/2007 12:42 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>"Clark, John" > <CLARKJ2@ccf.org></b> </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">07/20/2007 07:15 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">[XForms 1.1] Inserting into an empty > element (section 9.3.5  processing rule 6.a)</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > As I read the latest working draft of the XForms specification[0], I am<br> > unsure what will happen at processing rule 6.a if the cloned node is not<br> > an attribute and the `insert location node` does not have any children.<br> > In this case, "the target location is before the first child of the<br> > insert location node", but that is not well-defined if there is no > such<br> > first child.  I think it would be a significant gap in the > specification<br> > if the eventual language would not allow a node to be inserted into an<br> > empty element.<br> > <br> > Is there any chance that this could be clarified (hopefully in favor of<br> > being able to insert a node into an element with no children)?<br> > <br> > [0] </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert"><tt><font > size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/#action-insert</font></tt></a><tt><font > size=2><br> > <br> > Take care,<br> > <br> >   John L. Clark  |  Systems Analyst<br> >          | >  Cardio-Thoracic > Surgery Research<br> > Cleveland Clinic  |  9500 Euclid Ave.  |  Cleveland, > OH 44195<br> >          |  (216) > 445-6011<br> > <br> > ===================================<br> > <br> > Cleveland Clinic is ranked one of the top hospitals<br> > in America by U.S. News & World Report (2007).  <br> > Visit us online at </font></tt><a href=http://www.clevelandclinic.org/><tt><font > size=2>http://www.clevelandclinic.org</font></tt></a><tt><font size=2> > for<br> > a complete listing of our services, staff and<br> > locations.<br> > <br> > <br> > Confidentiality Note:  This message is intended for use<br> > only by the individual or entity to which it is addressed<br> > and may contain information that is privileged,<br> > confidential, and exempt from disclosure under applicable<br> > law.  If the reader of this message is not the intended<br> > recipient or the employee or agent responsible for<br> > delivering the message to the intended recipient, you are<br> > hereby notified that any dissemination, distribution or<br> > copying of this communication is strictly prohibited.  If<br> > you have received this communication in error,  please<br> > contact the sender immediately and destroy the material in<br> > its entirety, whether electronic or hard copy.  Thank you.<br> > <br> > <br> > <br> > <br> > </font></tt> > --=_alternative 006C3F4E88257329_=-- > >
PROBLEM ID: 122
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
We will simplify
ORIGINAL MESSAGE:
From: "Yves Savourel" <ysavourel@translate.com> --- 4) The example "G.1 XForms in XHTML" is actually something usually frown upon in localization: Having a source file in multiple languages. Such files are very difficult to process in a normal localization workflow. For example if you had to translate the file in German you would have to add HTML and XForm code rather than just take the English source and translate it. Also if you have the file to translate into several languages, you have to use different translator and re-consolidate the file after all are done (rather than translate in parallel. I realize this is just an example meant to illustrate many of XForm features, but if the same goal could be achieved in a monolingual file (not necessarily English) it would be much better from the perspective of internationalization.
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for this comment. On reviewing the example, we decided it was too complicated to be useful at this point, so we will replace it with a simpler example, that doesn't use multilingual text. Best wishes, Steven Pemberton For the Forms WG > --- 4) The example "G.1 XForms in XHTML" is actually something usually > frown upon in localization: Having a source file in multiple > languages. > > Such files are very difficult to process in a normal localization > workflow. For example if you had to translate the file in German > you would have to add HTML and XForm code rather than just take the > English source and translate it. Also if you have the file to > translate into several languages, you have to use different translator and > re-consolidate the file after all are done (rather than > translate in parallel. > > I realize this is just an example meant to illustrate many of XForm > features, but if the same goal could be achieved in a > monolingual file (not necessarily English) it would be much better from > the perspective of internationalization. > >
PROBLEM ID: 128
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> Add "Compound Document [Definition: A [CDRF 1.0] Compound Document is a document that combines mutliple document formats either by reference, by inclusion or both.]"
FOLLOWUP 1:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Kevin, The Forms WG agreed to add the definition as given below. It now appears in the editor's draft available from the working group web site. Best regards, John Boyer > > Add > "Compound Document > [Definition: A [CDRF 1.0] Compound Document is a document that > combines mutliple document formats either by reference, by inclusion > or both.]" > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Kevin, The Forms WG agreed to add the definition as given below. It now appears in the editor's draft available from the working group web site. Best regards, John Boyer > > Add > "Compound Document > [Definition: A [CDRF 1.0] Compound Document is a document that > combines mutliple document formats either by reference, by inclusion > or both.]" > >
PROBLEM ID: 120
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
It should have been "latte" anyway (it's Italian not French)
ORIGINAL MESSAGE:
From: "Yves Savourel" <ysavourel@translate.com> --- 2) In the example "G.3 Survey Using XForms and SVG" The 'é' in the different occurrences of 'latté' displays as a block in IE7 and as a '?' in FireFox. I'm guessing the HTML file is not in the encoding it declares.
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for your comment. We have now fixed this. Best wishes, Steven Pemberton For the Forms WG > --- 2) In the example "G.3 Survey Using XForms and SVG" > > The '�' in the different occurrences of 'latt�' displays as a block in IE7 > and as a '?' in FireFox. I'm guessing the HTML file is > not in the encoding it declares. > >
REPLY 2:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for your comment. We have now fixed this. Best wishes, Steven Pemberton For the Forms WG > --- 2) In the example "G.3 Survey Using XForms and SVG" > > The '�' in the different occurrences of 'latt�' displays as a block in IE7 > and as a '?' in FireFox. I'm guessing the HTML file is > not in the encoding it declares. > >
PROBLEM ID: 106
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: None
NOTES:
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". >>>>
ORIGINAL MESSAGE:
From: "Martin Duerst" <duerst@it.aoyama.ac.jp> Dear XForms Editors, This is a Last Call Comment on http://www.w3.org/TR/xforms11/. Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode), entitled "Input Modes", should be updated to be in sync with the most recent list of scripts from Unicode/ISO 10646. A rough count (using the Unix 'wc' utilty) showed that about 15 scripts are missing from the list of tokens at http://www.w3.org/TR/xforms11/#mode-values. A point-by-point comparison with http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt (look below the line "# Script (sc)") gave the following list (more than 15 because E.3.1 contains quite a few special values): (starting with lowercase and converting spaces to camelcase in line with the currently available tokens (e.g. canaidianAboriginal)). balinese buginese coptic cypriot glagolitic kharoshthi limbu linearB nko osmanya phagsPa phoenician shavian sylotiNagri taiLe newTaiLue tifinagh ugaritic oldPersian cuneiform This list of tokens can be included as is (with "Unicode script name" in the Comments column), but should be cross-checked to make sure I didn't miss anything. The text above the table can then be updated to say "The version of the Unicode Standard that these script name are taken from is 5.0." instead of "The version of the Unicode Standard that these script names are taken from is 3.2.". Many of the scripts (e.g. Cunieform) are not necessarily what you would expect as your typical XForms input, but some of the tokens already available in XForms 1.0 also don't have a high probability of usage, and it's better to be complete than to leave something out that later may be needed. Some people may raise the concern that adding these script tokens will force the spec to go to Last Call again. While this would be true for any genuinely new feature being added after Last Call, it is difficult to see why a new Last Call would be needed just because the list of scripts is being completed. No XForms implementation is forced to support all of these values anyway, but not including a value that's currently not supported would create a weird chicken-and-egg problem. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
FOLLOWUP 1:
From: public-i18n-core-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Martin, I wonder if it woudn't be more efficient to have this list by reference rather than by inclusion. Since you are the author of this section, would you be willing to suggest the text to replace the list with references to the normative specs? Best wishes, Steven Pemberton > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode), > entitled "Input Modes", should be updated to be in sync with the most > recent list of scripts from Unicode/ISO 10646. > > A rough count (using the Unix 'wc' utilty) showed that about 15 > scripts are missing from the list of tokens at > http://www.w3.org/TR/xforms11/#mode-values. > > A point-by-point comparison with > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt > (look below the line "# Script (sc)") gave the following list > (more than 15 because E.3.1 contains quite a few special values): > (starting with lowercase and converting spaces to camelcase in > line with the currently available tokens (e.g. canaidianAboriginal)). > > balinese > buginese > coptic > cypriot > glagolitic > kharoshthi > limbu > linearB > nko > osmanya > phagsPa > phoenician > shavian > sylotiNagri > taiLe > newTaiLue > tifinagh > ugaritic > oldPersian > cuneiform > > This list of tokens can be included as is (with "Unicode script name" > in the Comments column), but should be cross-checked to make sure > I didn't miss anything. The text above the table can then be updated > to say "The version of the Unicode Standard that these script name > are taken from is 5.0." instead of "The version of the Unicode Standard > that these script names are taken from is 3.2.". > > Many of the scripts (e.g. Cunieform) are not necessarily what you > would expect as your typical XForms input, but some of the tokens > already available in XForms 1.0 also don't have a high probability > of usage, and it's better to be complete than to leave something out > that later may be needed. > > Some people may raise the concern that adding these script tokens > will force the spec to go to Last Call again. While this would be > true for any genuinely new feature being added after Last Call, > it is difficult to see why a new Last Call would be needed just > because the list of scripts is being completed. No XForms implementation > is forced to support all of these values anyway, but not including > a value that's currently not supported would create a weird > chicken-and-egg problem. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > >
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Martin, I wonder if it woudn't be more efficient to have this list by reference rather than by inclusion. Since you are the author of this section, would you be willing to suggest the text to replace the list with references to the normative specs? Best wishes, Steven Pemberton > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode), > entitled "Input Modes", should be updated to be in sync with the most > recent list of scripts from Unicode/ISO 10646. > > A rough count (using the Unix 'wc' utilty) showed that about 15 > scripts are missing from the list of tokens at > http://www.w3.org/TR/xforms11/#mode-values. > > A point-by-point comparison with > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt > (look below the line "# Script (sc)") gave the following list > (more than 15 because E.3.1 contains quite a few special values): > (starting with lowercase and converting spaces to camelcase in > line with the currently available tokens (e.g. canaidianAboriginal)). > > balinese > buginese > coptic > cypriot > glagolitic > kharoshthi > limbu > linearB > nko > osmanya > phagsPa > phoenician > shavian > sylotiNagri > taiLe > newTaiLue > tifinagh > ugaritic > oldPersian > cuneiform > > This list of tokens can be included as is (with "Unicode script name" > in the Comments column), but should be cross-checked to make sure > I didn't miss anything. The text above the table can then be updated > to say "The version of the Unicode Standard that these script name > are taken from is 5.0." instead of "The version of the Unicode Standard > that these script names are taken from is 3.2.". > > Many of the scripts (e.g. Cunieform) are not necessarily what you > would expect as your typical XForms input, but some of the tokens > already available in XForms 1.0 also don't have a high probability > of usage, and it's better to be complete than to leave something out > that later may be needed. > > Some people may raise the concern that adding these script tokens > will force the spec to go to Last Call again. While this would be > true for any genuinely new feature being added after Last Call, > it is difficult to see why a new Last Call would be needed just > because the list of scripts is being completed. No XForms implementation > is forced to support all of these values anyway, but not including > a value that's currently not supported would create a weird > chicken-and-egg problem. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Martin, As we previously indicated to you, we noticed that the appendix was not marked informative, which was an error we have now corrected. We have deferred this issue for the CR transition because the appendix is informative. We would like to have your help in producing an update to this appendix which you previously wrote. Ideally, it would not contain another set of long lists, but rather would reference the appropriate technical specifications that contain those lists, and make some indication that documents which supercede those technical specifications may be used. This will allow people to add more script tokens over time as the relevant technical specifications are updated, without having to also update the XForms recommendation. Best regards, John Boyer > > Dear XForms Editors, > > This is a Last Call Comment on http://www.w3.org/TR/xforms11/. > > Appendix E of this specification (http://www.w3.org/TR/xforms11/#mode), > entitled "Input Modes", should be updated to be in sync with the most > recent list of scripts from Unicode/ISO 10646. > > A rough count (using the Unix 'wc' utilty) showed that about 15 > scripts are missing from the list of tokens at > http://www.w3.org/TR/xforms11/#mode-values. > > A point-by-point comparison with > http://www.unicode.org/Public/5.0.0/ucd/PropertyValueAliases.txt > (look below the line "# Script (sc)") gave the following list > (more than 15 because E.3.1 contains quite a few special values): > (starting with lowercase and converting spaces to camelcase in > line with the currently available tokens (e.g. canaidianAboriginal)). > > balinese > buginese > coptic > cypriot > glagolitic > kharoshthi > limbu > linearB > nko > osmanya > phagsPa > phoenician > shavian > sylotiNagri > taiLe > newTaiLue > tifinagh > ugaritic > oldPersian > cuneiform > > This list of tokens can be included as is (with "Unicode script name" > in the Comments column), but should be cross-checked to make sure > I didn't miss anything. The text above the table can then be updated > to say "The version of the Unicode Standard that these script name > are taken from is 5.0." instead of "The version of the Unicode Standard > that these script names are taken from is 3.2.". > > Many of the scripts (e.g. Cunieform) are not necessarily what you > would expect as your typical XForms input, but some of the tokens > already available in XForms 1.0 also don't have a high probability > of usage, and it's better to be complete than to leave something out > that later may be needed. > > Some people may raise the concern that adding these script tokens > will force the spec to go to Last Call again. While this would be > true for any genuinely new feature being added after Last Call, > it is difficult to see why a new Last Call would be needed just > because the list of scripts is being completed. No XForms implementation > is forced to support all of these values anyway, but not including > a value that's currently not supported would create a weird > chicken-and-egg problem. > > Regards, Martin. > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > >
PROBLEM ID: 121
STATE: Approved and Implemented
EDIT: N/A
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
Yes, we are doing this in collaboration with M Duerst. This is a duplicate of 106.
ORIGINAL MESSAGE:
From: "Yves Savourel" <ysavourel@translate.com> --- 3) The section "E.3.1 Script Tokens" lists possible values for inputMode. It says the values have been taken from Unicode 3.2. Maybe it's worth checking it against the latest version of Unicode (5.0 now) and make addition as needed? [Just a suggestion]
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Yes, we quite agree, and we are collaborating with Martin Duerst (the author of this section) to ensure that the list is correct. Thanks for the comment. Best wishes, Steven Pemberton For the Forms WG > --- 3) The section "E.3.1 Script Tokens" lists possible values for > inputMode. It says the values have been taken from Unicode 3.2. > Maybe it's worth checking it against the latest version of Unicode (5.0 > now) and make addition as needed? [Just a suggestion] > >
PROBLEM ID: 49
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Klotz, Leigh" <Leigh.Klotz@xerox.com> This may be a simple editing error, but the XForms 1.1 Working Draft [1] in the Normative References section [2] refers via [3] to XForms 1.0 Requirements [4] but does not cite XForms 1.1 Requirements [5]. [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm [4] http://www.w3.org/TR/xhtml-forms-req [5] http://www.w3.org/TR/xforms-11-req/ Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 requirements? Leigh L. Klotz, Jr. Xerox Corporation
FOLLOWUP 1:
From: w3c-forms-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- > This may be a simple editing error, but the XForms 1.1 Working Draft [1] > in the Normative References section [2] refers via [3] to XForms 1.0 > Requirements [4] but does not cite XForms 1.1 Requirements [5]. > > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm > [4] http://www.w3.org/TR/xhtml-forms-req > [5] http://www.w3.org/TR/xforms-11-req/ > > > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 > requirements? > > We removed the XForms 1.0 requirements and do not add XForms 1.1. > Leigh L. Klotz, Jr. > Xerox Corporation > > Regards, Ulrich Nicolas Lissé. For the Forms WG
FOLLOWUP 2:
From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com> This is a MIME-encapsulated message --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com The original message was received at Wed, 13 Jun 2007 15:14:07 -0500 from htmlwg.mn.aptest.com [127.0.0.1] ----- The following addresses had permanent fatal errors ----- <www-forms-editor@org> (reason: 550 Host unknown) ----- Transcript of session follows ----- 550 5.1.2 <www-forms-editor@org>... Host unknown (Name server: org: host not found) --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com Content-Type: message/delivery-status Reporting-MTA: dns; htmlwg.mn.aptest.com Received-From-MTA: DNS; htmlwg.mn.aptest.com Arrival-Date: Wed, 13 Jun 2007 15:14:07 -0500 Final-Recipient: RFC822; www-forms-editor@org Action: failed Status: 5.1.2 Remote-MTA: DNS; org Diagnostic-Code: SMTP; 550 Host unknown Last-Attempt-Date: Wed, 13 Jun 2007 15:14:07 -0500 --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: <xforms-issues@mn.aptest.com> Received: from htmlwg.mn.aptest.com (htmlwg.mn.aptest.com [127.0.0.1]) by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id l5DKE7rs006220; Wed, 13 Jun 2007 15:14:07 -0500 Date: Wed, 13 Jun 2007 15:14:07 -0500 Message-Id: <200706132014.l5DKE7rs006220@htmlwg.mn.aptest.com> From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> To: Leigh.Klotz@xerox.com Subject: Re: Last Call Comment: XForms 1.1 refers normatively to XForms 1.0 requirements but not XForms 1.1 requirements (PR#49) CC: w3c-forms@w3.org, www-forms-editor@org X-Loop: xforms-issues@mn.aptest.com > This may be a simple editing error, but the XForms 1.1 Working Draft [1] > in the Normative References section [2] refers via [3] to XForms 1.0 > Requirements [4] but does not cite XForms 1.1 Requirements [5]. > > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm > [4] http://www.w3.org/TR/xhtml-forms-req > [5] http://www.w3.org/TR/xforms-11-req/ > > > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 > requirements? > > We removed the XForms 1.0 requirements and do not add XForms 1.1. > Leigh L. Klotz, Jr. > Xerox Corporation > > Regards, Ulrich Nicolas Lissé. For the Forms WG --l5DKEErs006223.1181765654/htmlwg.mn.aptest.com--
FOLLOWUP 3:
From: "Klotz, Leigh" <Leigh.Klotz@xerox.com> Thank you. -----Original Message----- From: Steven Pemberton [mailto:xforms-issues@mn.aptest.com] Sent: Wednesday, June 13, 2007 1:25 PM To: Klotz, Leigh Cc: www-forms-editor@w3.org Subject: Re: Last Call Comment: XForms 1.1 refers normatively to XForms 1.0 requirements but not XForms 1.1 requirements (PR#49) Leigh, thanks for your comment. > This may be a simple editing error, but the XForms 1.1 Working Draft [1] > in the Normative References section [2] refers via [3] to XForms 1.0 > Requirements [4] but does not cite XForms 1.1 Requirements [5]. >[1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm > [4] http://www.w3.org/TR/xhtml-forms-req > [5] http://www.w3.org/TR/xforms-11-req/ >Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 > requirements? > We have resolved to remove the unreferenced XForms 1.0 requirements and therefore will not add XForms 1.1. Regards, Steven Pemberton For the Forms WG
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Leigh, thanks for your comment. > This may be a simple editing error, but the XForms 1.1 Working Draft [1] > in the Normative References section [2] refers via [3] to XForms 1.0 > Requirements [4] but does not cite XForms 1.1 Requirements [5]. >[1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm > [4] http://www.w3.org/TR/xhtml-forms-req > [5] http://www.w3.org/TR/xforms-11-req/ >Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 > requirements? > We have resolved to remove the unreferenced XForms 1.0 requirements and therefore will not add XForms 1.1. Regards, Steven Pemberton For the Forms WG
REPLY 2:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> > This may be a simple editing error, but the XForms 1.1 Working Draft [1] > in the Normative References section [2] refers via [3] to XForms 1.0 > Requirements [4] but does not cite XForms 1.1 Requirements [5]. > > [1] http://www.w3.org/TR/2007/WD-xforms11-20070222/ > [2] http://www.w3.org/TR/2007/WD-xforms11-20070222/#ref-xforms-req > [3] http://www.w3.org/TR/2007/WD-xforms11-20070222/#references-norm > [4] http://www.w3.org/TR/xhtml-forms-req > [5] http://www.w3.org/TR/xforms-11-req/ > > > Should it refer only to XForms 1.1 requirements, or to both 1.0 and 1.1 > requirements? > > We removed the XForms 1.0 requirements and do not add XForms 1.1. > Leigh L. Klotz, Jr. > Xerox Corporation > > Regards, Ulrich Nicolas Lissé. For the Forms WG
PROBLEM ID: 90
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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).
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, What is supposed to happen with the following: <xforms:select ref="value"> <xforms:label>Flavors</xforms:label> <xforms:item> <xforms:label>Empty</xforms:label> <xforms:value></xforms:value> </xforms:item> <xforms:item> <xforms:label>Chocolate</xforms:label> <xforms:value>chocolate</xforms:value> </xforms:item> </xforms:select> The key here is the first item value being empty. Now if I have the following in the instance: <value></value> Is the first item, "Empty". supposed to be visually selected? What if I have this: <value>chocolate</value> Clearly, "Chocolate" is selected. But then would "Empty" be selected? -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
PROBLEM ID: 89
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, Assume again an instance containing the following: <value>vanilla strawberry elephant</value> and the following xforms:select control: <xforms:select ref="value"> <xforms:label>Flavors</xforms:label> <xforms:item> <xforms:label>Chocolate</xforms:label> <xforms:value>chocolate</xforms:value> </xforms:item> <xforms:item> <xforms:label>Vanilla</xforms:label> <xforms:value>vanilla</xforms:value> </xforms:item> <xforms:item> <xforms:label>Strawberry</xforms:label> <xforms:value>strawberry</xforms:value> </xforms:item> <xforms:item> <xforms:label>Hazelnut</xforms:label> <xforms:value>hazelnut</xforms:value> </xforms:item> </xforms:select> Now it seems that the control will be out of range if I guess enough from the spec. Now what happens if I select "hazelnut" from the control? 1. First, is the control functional at all if out of range? I don't read otherwise in the spec. 2. If it is functional, then does it append the "halzenut" value to the sequence of values, or does it replace the current value entirely? I.e. which of the following does it produce: a. <value>vanilla strawberry elephant hazelnut</value> b. <value>vanilla strawberry hazelnut</value> c. (any other possibility?) -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
PROBLEM ID: 117
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 26) Section 8.1.1 - "If a form control violates its data binding restriction, an xforms-binding-exception must occur." How can a form control violate its data binding restriction? I would think that the bound data would violate the data binding restriction of the control. 27) Section 8.1.1 - a bulleted list of "Form control must..." items, but no examples. Any suggestions for how I would "...render upon request an explanation of the current state of a form control..."? And what is the request? 28) Section 8.1.1 - the list of events that happen when a form control goes from being irrelevant to relevant -> xforms-value-changed only MIGHT be generated. A control can become relevant without the value of the control's bound node changing at all. 29) Section 8.1.5 - the description is duplicated. 30) Section 8.3.3 - "This required element labels the containing form control with a descriptive label." This isn't always required. For example repeat, output, choices, group, and case.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, Here are responses to a number of issues that you raised in a last call comment email on April 30. Spec changes can be found in the editor's copy available from the Forms WG public site. Please let us know if you have any further concerns about these issues. Thanks, John Boyer 26) Section 8.1.1 - "If a form control violates its data binding restriction, an xforms-binding-exception must occur." How can a form control violate its data binding restriction? I would think that the bound data would violate the data binding restriction of the control. A form control can violate its data binding restriction by expressing a binding that resolves to a node of a forbidden datatype. Each form control expresses its data binding restrictions. 27) Section 8.1.1 - a bulleted list of "Form control must..." items, but no examples. Any suggestions for how I would "...render upon request an explanation of the current state of a form control..."? And what is the request? That bullet point and the one following have been removed. Diff-marked. 28) Section 8.1.1 - the list of events that happen when a form control goes from being irrelevant to relevant -> xforms-value-changed only MIGHT be generated. A control can become relevant without the value of the control's bound node changing at all. This was actually part of an erratum to XForms 1.0, not just new to 1.1. The intent here was to issue xforms-value-changed to the control when it becomes relevant even if there was no change of value. Implementations are not expected to store the state of UI controls when last they were relevant, nor are they required to store the changing states of controls based on their binding to a non-relevant node. And last, implementations need not then choose which state is the pertinent one for producing an xforms-value-changed. 29) Section 8.1.5 - the description is duplicated. Done. Diff-marked. 30) Section 8.3.3 - "This required element labels the containing form control with a descriptive label." This isn't always required. For example repeat, output, choices, group, and case. Fixed. Diff-marked. Improved wording of paragraph as well.
PROBLEM ID: 88
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, In section 8.1.10, I read: "For closed selections: If the initial instance value matches the storage value of one or more of the given items, those items are selected. If there is no match, no items are initially selected. If any selected values do not have a choice with a matching storage value, the form control must indicate an out-of-range condition." (Note that this dates back to XForms 1.0 first edition.) I have issues with this terminology. 1. The term "storage value" for an item appears only in section 8.1.10 and does not have a definition. It should have a clear definition, or another wording should be used. 2. The term "matching" is quite informal. Do we mean that there is string equality? This should be clarified. 3. "If any selected values [...]": selected where? I don't think we mean a selected item here. We probably mean that a value appears in the sequence of space-separated values? 4. "[a value] does not have a choice with [...]": is this even English? I guess that #3 and #4 mean that if I have an instance like this: <value>vanilla strawberry elephant</value> and the following item values provided to the xforms:select control with a closed selection: chocolate vanilla strawberry hazelnut then the control indicates an out-of-range condition. Is my guess right? We should in my opinion: 1. Clarify #3 and #4, that is the last sentence of the paragraph. 2. Ideally, rewrite the whole thing to use a consistent terminology. This is another of these cases where I think what we are trying to specify is quite simple, but where the wording is imprecise and misleading. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
PROBLEM ID: 72
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#ui-output "It is used to display values from the instance, and is treated as display:inline for purposes of layout." This should say that its default styling is display:inline. Note that other controls do not have this information, which gets in the way of interoperability, since different implementations may have different defaults for controls. Similarly, the read-only, relevant, invalid, and required properties should be required to have some default value (I have used at least one implementation which required a style sheet before invalid values were visible.)
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, We accepted your comments, and the spec will be updated accordingly. Regards, Nick Van den Bleeken > > http://www.w3.org/TR/xforms11/#ui-output > > "It is used to display values from the instance, and is treated as > display:inline for purposes of layout." > > This should say that its default styling is display:inline. > > Note that other controls do not have this information, which gets in > the way of interoperability, since different implementations may have > different defaults for controls. > > Similarly, the read-only, relevant, invalid, and required properties > should be required to have some default value (I have used at least > one implementation which required a style sheet before invalid values > were visible.) > >
PROBLEM ID: 73
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#ui-commonelems-mediatype We now have <output ref="piccy" mediatype="image/png"> and <output ref="piccy"><mediatype ref="../type"/></output> It would be better if it used @value instead of @ref, since then you could write: <output ref="data"><mediatype value="concat('image/', type)"/></output> Even better, since the attribute is completely new, is to do away with the mediatype element altogether: <output ref="data" mediatype="../type"/> (which would require <output ref="data" mediatype="'image/png'"> for the literal case.) The way that mediatype@ref has two different purposes depending on its parent element is nasty.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, As you know from the face to face meeting, the working group accepted a modified form of this comment. To simplify authoring of the mediatype child of output, a value attribute has been added. This helps address the mismatch you felt was problematic between using mediatype/@ref in upload vs. in output. However, the ref attribute was retained as an alternative because when upload and output are being used together, they both will have a mediatype element with a ref that indicates the same node. The results of the change are now available in the editor's draft available from the working group web site. Best regards, John Boyer > > http://www.w3.org/TR/xforms11/#ui-commonelems-mediatype > > We now have > > <output ref="piccy" mediatype="image/png"> > > and > > <output ref="piccy"><mediatype ref="../type"/></output> > > It would be better if it used @value instead of @ref, since then you > could write: > > <output ref="data"><mediatype value="concat('image/', type)"/></output> > > Even better, since the attribute is completely new, is to do away with > the mediatype element altogether: > > <output ref="data" mediatype="../type"/> > > (which would require > <output ref="data" mediatype="'image/png'"> > for the literal case.) > > The way that mediatype@ref has two different purposes depending on its > parent element is nasty. > > >
PROBLEM ID: 30
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Gary F Stevens" <gfsteven@us.ibm.com> In the XForms 1.1 Working Draft section 8.1.5 begins with two separate descriptions of the output element. They are phrased slightly differently from each other, but only one of the two descriptions is needed. Gary F Stevens Software Group - Emerging Standards IBM/US/Raleigh-RTP
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> You are right. The first description is the original, and should just be deleted. Many thanks. Steven Pemberton For the Forms WG > In the XForms 1.1 Working Draft section 8.1.5 begins with two separate > descriptions of the output element. They are phrased slightly differently > from each other, but only one of the two descriptions is needed. > > Gary F Stevens > Software Group - Emerging Standards > IBM/US/Raleigh-RTP > >
PROBLEM ID: 18
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> In Section 4.4.6, the xforms-delete event is discussed. The deleted-nodes property states that the deleted "nodes are no longer referenced by their parents." It is strongly implied but not stated that the detachment is only one way, i.e. that the nodes still reference their parents. It should be clarified that it is possible to traverse upward to the former ancestors of the deleted nodes. This should also be normatively stated in the section on the delete action (Section 9.3.6, bullet point 4). Currently that text simply says the nodes are deleted but it leaves open to interpretation what deleted actually means. It should say that the nodes are detached from their parents and queued for destruction immediately before deferred update behavior. Finally, the behavior of properly destroying all 'deleted' nodes before deferred update behavior occurs should be mentioned at the beginning of Section 10 on XForms actions. John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> It was necessary to remove this notion of half-detached nodes. Although it would be nice to be able to determine the parents of deleted nodes so that behaviors can be taken based on the exact nodes deleted, but there is no reasonable way to do this that always works. Moreover, for the cases that work via this method, the same cases already work with other event information. John Boyer > In Section 4.4.6, the xforms-delete event is discussed. > > The deleted-nodes property states that the deleted "nodes are no longer > referenced by their parents." It is strongly implied but not stated that > the detachment is only one way, i.e. that the nodes still reference their > parents. > > It should be clarified that it is possible to traverse upward to the > former ancestors of the deleted nodes. > > This should also be normatively stated in the section on the delete action > (Section 9.3.6, bullet point 4). Currently that text simply says the > nodes are deleted but it leaves open to interpretation what deleted > actually means. > > It should say that the nodes are detached from their parents and queued > for destruction immediately before deferred update behavior. > > Finally, the behavior of properly destroying all 'deleted' nodes before > deferred update behavior occurs should be mentioned at the beginning of > Section 10 on XForms actions. > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 36
STATE: Suspended
EDIT: N/A
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
Accepted, but deferred
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, What this is about ------------------ This comment is about xforms-compute-exception and xforms-binding-exception, in particular: * The clarity (or lack thereof) of the current wording. * The need for an xforms-compute-error event. The current text ---------------- For reference: Section "4.5.4 The xforms-compute-exception Event" says: "Dispatched as an indication of: an error occurring during XPath evaluation for a model item property [...]" The introduction to section "7 XPath Expressions in XForms" says: "XPath expressions that are not syntactically valid, including attempted calls to undefined functions, result in an exception (4.5.4 The xforms-compute-exception Event), except for binding expressions, which produce a different exception (4.5.1 The xforms-binding-exception Event)." Section "7.6 The XForms Function Library" says: "If an error occurs in an XPath function, an xforms-compute-exception occurs if the function appears in the expression of a model item property. If the error occurs in a function that appears in any other XForms attribute that contains an XPath expression, such as nodeset, ref or at, then an xforms-binding exception occurs." Section "7.12 Extension Functions" says: "XForms Processors perform this check at the time the document is loaded, and stop processing by signaling an exception (4.5.4 The xforms-compute-exception Event) if the XForms document declares an extension function for which the processor does not have an implementation." One thing to keep in mind ------------------------- As hinted by Mike Kay in his LC comments [1] from the XSL and XQuery WG, XPath 2.0 explicitly makes a distinction between two types of errors: static errors (which do not require evaluating expressions, i.e. typically syntactic errors) and dynamic errors (errors occurring while evaluating the XPath expression). I think that in XPath 1.0, the behavior of standard functions is designed so that you don't get dynamic errors. For example, converting a string to a number type will return NaN if the conversion fails, while with XPath 2.0 casting an xs:string that does not represent an integer to xs:integer will raise a runtime error. This said, while XPath 1.0 does not make this distinction explicitly, XForms does talk about a type of dynamic errors in the intro to section 7.6 under "if an error occurs in an XPath function", and also mentions errors occurring "during XPath evaluation" in section 4.5.4. So we do have, in XForms 1.0, static AND dynamic XPath errors, whether these terms are used or not. The problems ------------ I am confused by the current text, which in my eyes contradicts itself at times, and does not clearly lay out the intent of these events. 1. Section 7 indicates with the words "binding expressions" that the intent of a "binding exception" is to signal there is an error with a binding, whether the syntax is incorrect or whether there is a runtime error. I understand this to regard any XPath expression not only in xforms:bind/@nodeset but also in @ref/@nodeset expressions that bind controls to instance data. Issue #1: Section 7.6 says that syntax errors in attribute @at dispatch xforms-binding-exception. I think that this is wrong, as @at does not define a binding at all. (Note that xforms-binding-exception can also be dispatched for mismatched ids, etc., but here I am only interested in XPath expressions). 2. It seems that section 7.12 is the only place where the spec hints that the XForms engine must check the syntax of XPath expressions. Issue #2: It must be made 100% explicit that during XForms initialization (exact place TBD), every single XPath expression in the XForms document is checked for its syntax, and not only for undeclared extension functions. This includes XPath expressions on XForms actions, such as xforms:setvalue/@value, etc., XPath expressions in @if and @while attributes on actions as well, and also @context on actions. Such static XPath errors should dispatch xforms-binding-exception or xforms-compute-exception depending on whether the XPath expression is in a binding or not (see #4 below as well). 3. xforms-binding-exception is not cancelable and halts XForms processing altogether. It seems reasonable to do this for MIP and control bindings, because there isn't much you can do with such an error in your XForms document. But what about other uses of @ref and @nodeset? Issue #3: Is it reasonable to dispatch xforms-binding-exception and fatally stop XForms processing for xforms:setvalue/@ref or xforms:insert/@nodeset? I think that the answer to this question is "yes" provided issue #2 above is resolved to mandate that all expressions are checked for syntax during initialization. 4. @ref and @nodeset on actions are single-node and node-set bindings respecively, but they don't act like MIP or control bindings. Issue #4: Should errors in XPath expressions on @ref and @nodeset on actions dispatch xforms-binding-exception or xforms-compute-exception? An action is not really "bound" to a node as a MIP or control is. So as a form author, I am not sure why xforms:setvalue/@ref would dispatch a different event from xforms:setvalue/@value. 5. My understanding is that errors in other XPath expressions, including xforms:bind/@calculate, xforms:insert/@at, xforms:setvalue/@value, etc. should dispatch xforms-compute-exception. But the problem with this is that any error, whether static or dynamic, halts XForms engine processing altogether. This is not a huge problem with XPath 1.0, as mentioned above, since dynamic errors are fairly rare (if possible at all with the standard XPath 1.0 function library) and most likely confined to extension functions. Still, it appears reasonable to think that you can recover from dynamic XPath errors, and this is certainly the case when such errors do not occur in bindings. This also prepares XForms for a future where XPath 2.0 is supported, as also suggested by Mike Kay in [1]. Issue #5: Dynamic XPath errors should dispatch a new event: xforms-compute-error (and possibly xforms-binding-error), which do not halt XForms engine processing. Whether to support xforms-binding-error for MIP and control bindings can be discussed, but it would make sense for xforms:setvalue/@ref and the likes as those errors can often be recovered. A possible strategy ------------------- Here is a tentative strategy based on the above: * Dispatch xforms-binding-exception for static XPath errors occurring in @ref and @nodeset expressions on xforms:bind and controls bindings. Static errors must be checked during XForms engine initialization. * Also dispatch xforms-binding-exception for dynamic XPath errors occurring in @ref and @nodeset expressions on xforms:bind and controls bindings. * Dispatch xforms-compute-exception for static XPath errors occurring anywhere else, including single-node or node-set bindings on actions. Static errors must be checked during XForms engine initialization. * Dispatch xforms-compute-error (a new event) for dynamic XPath errors occurring anywhere else. While this is done, the relevant text in the spec should be consolidated and clarified. -Erik [1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, The working group acknowledges that a richer array of exceptions, or possibly a more general exception with better context information, is needed to more accurately characterize the exceptions that occur when evaluating XPath expressions. The bulk of the problem seems to be that binding exceptions are being issued for XPaths that are not strictly bindings. In one important case, we do already have a separate exception, compute exception, that is thrown instead of binding exception when a fatal error occurs in a MIP expression (i.e. any attribute of a bind element except for nodeset). It would be fair to say though, that xforms-binding-exception is really being treated more like xforms-binding-or-xpath-exception at this time. The working group also acknowledges the utility of analyzing the cases currently associated with exceptions to find those that would be better to have as non-fatal errors. The working group resolved to accept these points and to defer the changes to a future version of XForms. Thank you, John Boyer > > All, > > What this is about > ------------------ > > This comment is about xforms-compute-exception and > xforms-binding-exception, in particular: > > * The clarity (or lack thereof) of the current wording. > * The need for an xforms-compute-error event. > > The current text > ---------------- > > For reference: > > Section "4.5.4 The xforms-compute-exception Event" says: > > "Dispatched as an indication of: an error occurring during XPath > evaluation for a model item property [...]" > > The introduction to section "7 XPath Expressions in XForms" says: > > "XPath expressions that are not syntactically valid, including > attempted calls to undefined functions, result in an exception > (4.5.4 The xforms-compute-exception Event), except for binding > expressions, which produce a different exception (4.5.1 The > xforms-binding-exception Event)." > > Section "7.6 The XForms Function Library" says: > > "If an error occurs in an XPath function, an > xforms-compute-exception occurs if the function appears in the > expression of a model item property. If the error occurs in a > function that appears in any other XForms attribute that contains > an XPath expression, such as nodeset, ref or at, then an > xforms-binding exception occurs." > > Section "7.12 Extension Functions" says: > > "XForms Processors perform this check at the time the document is > loaded, and stop processing by signaling an exception (4.5.4 The > xforms-compute-exception Event) if the XForms document declares an > extension function for which the processor does not have an > implementation." > > One thing to keep in mind > ------------------------- > > As hinted by Mike Kay in his LC comments [1] from the XSL and XQuery > WG, XPath 2.0 explicitly makes a distinction between two types of > errors: static errors (which do not require evaluating expressions, > i.e. typically syntactic errors) and dynamic errors (errors occurring > while evaluating the XPath expression). > > I think that in XPath 1.0, the behavior of standard functions is > designed so that you don't get dynamic errors. For example, converting > a string to a number type will return NaN if the conversion fails, > while with XPath 2.0 casting an xs:string that does not represent an > integer to xs:integer will raise a runtime error. > > This said, while XPath 1.0 does not make this distinction explicitly, > XForms does talk about a type of dynamic errors in the intro to > section 7.6 under "if an error occurs in an XPath function", and also > mentions errors occurring "during XPath evaluation" in section > 4.5.4. So we do have, in XForms 1.0, static AND dynamic XPath errors, > whether these terms are used or not. > > The problems > ------------ > > I am confused by the current text, which in my eyes contradicts itself > at times, and does not clearly lay out the intent of these events. > > 1. Section 7 indicates with the words "binding expressions" that the > intent of a "binding exception" is to signal there is an error with > a binding, whether the syntax is incorrect or whether there is a > runtime error. I understand this to regard any XPath expression not > only in xforms:bind/@nodeset but also in @ref/@nodeset expressions > that bind controls to instance data. > > Issue #1: Section 7.6 says that syntax errors in attribute @at > dispatch xforms-binding-exception. I think that this is wrong, as > @at does not define a binding at all. > > (Note that xforms-binding-exception can also be dispatched for > mismatched ids, etc., but here I am only interested in XPath > expressions). > > 2. It seems that section 7.12 is the only place where the spec hints > that the XForms engine must check the syntax of XPath expressions. > > Issue #2: It must be made 100% explicit that during XForms > initialization (exact place TBD), every single XPath expression in > the XForms document is checked for its syntax, and not only for > undeclared extension functions. This includes XPath expressions on > XForms actions, such as xforms:setvalue/@value, etc., XPath > expressions in @if and @while attributes on actions as well, and > also @context on actions. Such static XPath errors should dispatch > xforms-binding-exception or xforms-compute-exception depending on > whether the XPath expression is in a binding or not (see #4 below > as well). > > 3. xforms-binding-exception is not cancelable and halts XForms > processing altogether. It seems reasonable to do this for MIP and > control bindings, because there isn't much you can do with such an > error in your XForms document. But what about other uses of @ref > and @nodeset? > > Issue #3: Is it reasonable to dispatch xforms-binding-exception > and fatally stop XForms processing for xforms:setvalue/@ref or > xforms:insert/@nodeset? > > I think that the answer to this question is "yes" provided issue #2 > above is resolved to mandate that all expressions are checked for > syntax during initialization. > > 4. @ref and @nodeset on actions are single-node and node-set bindings > respecively, but they don't act like MIP or control bindings. > > Issue #4: Should errors in XPath expressions on @ref and @nodeset > on actions dispatch xforms-binding-exception or > xforms-compute-exception? > > An action is not really "bound" to a node as a MIP or control > is. So as a form author, I am not sure why xforms:setvalue/@ref > would dispatch a different event from xforms:setvalue/@value. > > 5. My understanding is that errors in other XPath expressions, > including xforms:bind/@calculate, xforms:insert/@at, > xforms:setvalue/@value, etc. should dispatch > xforms-compute-exception. > > But the problem with this is that any error, whether static or > dynamic, halts XForms engine processing altogether. This is not a > huge problem with XPath 1.0, as mentioned above, since dynamic > errors are fairly rare (if possible at all with the standard XPath > 1.0 function library) and most likely confined to extension > functions. > > Still, it appears reasonable to think that you can recover from > dynamic XPath errors, and this is certainly the case when such > errors do not occur in bindings. This also prepares XForms for a > future where XPath 2.0 is supported, as also suggested by Mike Kay > in [1]. > > Issue #5: Dynamic XPath errors should dispatch a new event: > xforms-compute-error (and possibly xforms-binding-error), which > do not halt XForms engine processing. Whether to support > xforms-binding-error for MIP and control bindings can be > discussed, but it would make sense for xforms:setvalue/@ref and > the likes as those errors can often be recovered. > > A possible strategy > ------------------- > > Here is a tentative strategy based on the above: > > * Dispatch xforms-binding-exception for static XPath errors occurring > in @ref and @nodeset expressions on xforms:bind and controls > bindings. Static errors must be checked during XForms engine > initialization. > > * Also dispatch xforms-binding-exception for dynamic XPath errors > occurring in @ref and @nodeset expressions on xforms:bind and > controls bindings. > > * Dispatch xforms-compute-exception for static XPath errors occurring > anywhere else, including single-node or node-set bindings on > actions. Static errors must be checked during XForms engine > initialization. > > * Dispatch xforms-compute-error (a new event) for dynamic XPath errors > occurring anywhere else. > > While this is done, the relevant text in the spec should be > consolidated and clarified. > > -Erik > > [1] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 50
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, At the moment, I don't think this is clearly specified to happen. Use case: 1. <xforms:input ref="name"> 2. The instance containing "name" is replaced. 3. Section 11.2 specifies that a refresh must take place. However, no node of the new instance is marked as having changed as I understand it. 4.3.4 says "If the value of an instance data node was changed, then the node must be marked for dispatching the xforms-value-changed event.". But in this case, the value of the node hasn't changed because the node is just freshly created from the instance replacement. 4. Consequence: no xforms-value-changed is fired. This behavior is very non-intuitive because you can replace an instance under controls' feet and while the control may update their values in the UI, no xforms-value-changed is fired. This means that you cannot reliably use events to determine if the value of a control has changed or not. I think that this should be possible, or the usefulness of value-changed-events is greatly reduced. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Erik, we recognize the problem, but defer changes to MIP events for now because we need a broader based redesign of events for controls and possibly also for model. Regards, Ulrich Nicolas Lissé For the Forms WG> All, > > At the moment, I don't think this is clearly specified to happen. > > Use case: > > 1. <xforms:input ref="name"> > > 2. The instance containing "name" is replaced. > > 3. Section 11.2 specifies that a refresh must take place. However, no > node of the new instance is marked as having changed as I > understand it. 4.3.4 says "If the value of an instance data node > was changed, then the node must be marked for dispatching the > xforms-value-changed event.". But in this case, the value of the > node hasn't changed because the node is just freshly created from > the instance replacement. > > 4. Consequence: no xforms-value-changed is fired. > > This behavior is very non-intuitive because you can replace an > instance under controls' feet and while the control may update their > values in the UI, no xforms-value-changed is fired. > > This means that you cannot reliably use events to determine if the > value of a control has changed or not. I think that this should be > possible, or the usefulness of value-changed-events is greatly > reduced. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > > >
PROBLEM ID: 115
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if there is a host-language defined linking attribute. 16) Section 4.3.2 - mentions the special case of focusing a repeat, but not the special cases of group and switch. Why not? 17) Section 4.3.5 - "...then either the xforms-valid event must be marked for dispatch if the node changes from valid to invalid..." I assume that is a typo? Other way around, I'd think. 18) Section 4.3.6 - the paragraph that mentions 'circular dependency' is pretty confusing on the whole. Could really use an example or two, especially the circular dependency part. 19) Section 4.6.9 - doesn't mention the xforms-submit-serialize event. 20) Section 4.7.1 - I found the second paragraph very confusing. 21) Section 4.7.2 - "However, if the target bind element has one or more bind element ancestors, then the identified bind may be a target element that is associated with more than one target bind object." Huh?
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, The following are responses to a number of issues you raised in an Email dated April 30th. Please let us know if you have any further concerns about these issues. The changes can be viewed in the editor's draft of the spec appearing on the working group website. Thanks, John Boyer 17) Section 4.3.5 - "...then either the xforms-valid event must be marked for dispatch if the node changes from valid to invalid..." I assume that is a typo? Other way around, I'd think. Fixed. Not diff-marked. 18) Section 4.3.6 - the paragraph that mentions 'circular dependency' is pretty confusing on the whole. Could really use an example or two, especially the circular dependency part. Examples were added. Diff marked. 19) Section 4.6.9 - doesn't mention the xforms-submit-serialize event. Done. Diff-marked. 20) Section 4.7.1 - I found the second paragraph very confusing. It is necessary to consider the parse tree of the document, annotated by run-time objects generated for and associated with the document markup. The referring object that contains an IDREF appears at location X in the parse tree, and the element bearing the matching ID is at location Y in the parse tree. Take the paths of ancestors from X to root element and from Y to root. X and Y will have some ancestors in common and some that are not. This subsection is not intended to be read separately from its immediately containing section (4.7). 21) Section 4.7.2 - "However, if the target bind element has one or more bind element ancestors, then the identified bind may be a target element that is associated with more than one target bind object." Huh? This section is talking about the difference between declared bind elements and run-time bind objects. Suppose the inner bind is the target element of an IDREF. The inner bind is associated with one bind object for each node of the nodeset of an outer bind. This subsection is not intended to be read separately from its immediately containing section (4.7).
PROBLEM ID: 57
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#rpm-events In the overview table, xforms-rebuild should be moved to after xforms-recalculate (to match the order that they are described). xforms-submit-error should be moved to the Error indications section. xforms-output-error is missing from the overview.
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > http://www.w3.org/TR/xforms11/#rpm-events > > In the overview table, xforms-rebuild should be moved to after > xforms-recalculate (to match the order that they are described). > xforms-submit-error should be moved to the Error indications section. > xforms-output-error is missing from the overview. > >
PROBLEM ID: 155
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
The editor's draft contains spec-ready text for this in 4.3.2.
ORIGINAL MESSAGE:
From: aaronr@us.ibm.com Full_Name: Aaron Reed Submission from: (NULL) (32.97.110.142) Submitted by: boyerj Date: Mon, 30 Apr 2007 23:56:50 +0200 To: www-forms-editor@w3.org Subject: Section 9 From: "Aaron Reed" <aaronr@us.ibm.com> 16) Section 4.3.2 - mentions the special case of focusing a repeat, but not the special cases of group and switch. Why not?
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Aaron, We updated the spec accordingly[1]. The latest editor's draft available from the Forms WG home page contains a correction. Please see the diff-marked version. [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-focus > Full_Name: Aaron Reed > Submission from: (NULL) (32.97.110.142) > Submitted by: boyerj > > > Date: Mon, 30 Apr 2007 23:56:50 +0200 > To: www-forms-editor@w3.org > Subject: Section 9 > From: "Aaron Reed" <aaronr@us.ibm.com> > > 16) Section 4.3.2 - mentions the special case of focusing a repeat, but not > the special cases of group and switch. Why not? > >
PROBLEM ID: 95
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#evt-recalculate Says: "Note: Authors should not refer to the current node's value in calculate expressions because the effect is not well-defined. Other model item properties, such as required or readonly, however, are well-defined in the presence of self-references." Are we sure we agree? I believe I have seen XForms that have ".+1". Steven
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven Many thanks for this comment. We have changed the spec accordingly. Best wishes, Nick Van den Bleeken For the Forms WG > > > http://www.w3.org/TR/xforms11/#evt-recalculate > > Says: "Note: > > Authors should not refer to the current node's value in calculate > expressions because the effect is not well-defined. Other model item > properties, such as required or readonly, however, are well-defined in the > presence of self-references." > > Are we sure we agree? I believe I have seen XForms that have ".+1". > > Steven > >
PROBLEM ID: 108
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, This is a comment about the "binding" property or these sections. Section 4.4.5 says: "The attribute value of the insert action's nodeset or bind attribute." However, both @bind and @nodeset are optional with xforms:insert. We should say what the "binding" property returns when this occurs. By the way, I believe I raised this in the past already, but I am not sure why this property is useful anyway. I would suggest simply getting rid of it unless a compelling use case for it is proposed. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Erik, we accept your request to clarify that the empty is string is returned by insert event binding if none is specified. We also ask for clarification on the feature and its use case, because in general, it is not possible for the form author to resolve the value without knowing the context and without knowing whether the binding is a bind IDREF or an XPath expression. Regards, Ulrich Nicolas Lissé. For the Forms WG > All, > > This is a comment about the "binding" property or these sections. > Section 4.4.5 says: > > "The attribute value of the insert action's nodeset or bind attribute." > > However, both @bind and @nodeset are optional with xforms:insert. We > should say what the "binding" property returns when this occurs. > > By the way, I believe I raised this in the past already, but I am not > sure why this property is useful anyway. I would suggest simply getting > rid of it unless a compelling use case for it is proposed. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 29
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, XForms 1.1 is much more specific than XForms 1.0 about sending MIP events, in particular what events to send when controls become relevant and non-relevant. This is good. The motivation for this was, in my opinion, to make the MIP events actually useful, because they now can be used to reliably track the status of controls. However, there is one hole: the spec does not mention that any MIP events should be sent during XForms engine initialization. In particular, there is no initial xforms-refresh, or otherwise requirement that MIP events should be dispatched upon initialization. This means that it is currently not possible to determine the initial status (in particular, validity) of the controls. This affects for example the use case of creating an error summary that tracks the validity of controls in your page. I think that controls should initially dispatch MIP events so as to make this use case possible. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Erik, we recognize the problem, but defer changes to MIP events for now because we need a broader based redesign of events for controls and possibly also for model. Regards, Ulrich Nicolas Lissé For the Forms WG > All, > > XForms 1.1 is much more specific than XForms 1.0 about sending MIP > events, in particular what events to send when controls become > relevant and non-relevant. This is good. The motivation for this was, > in my opinion, to make the MIP events actually useful, because they > now can be used to reliably track the status of controls. > > However, there is one hole: the spec does not mention that any MIP > events should be sent during XForms engine initialization. In > particular, there is no initial xforms-refresh, or otherwise > requirement that MIP events should be dispatched upon initialization. > > This means that it is currently not possible to determine the initial > status (in particular, validity) of the controls. > > This affects for example the use case of creating an error summary > that tracks the validity of controls in your page. > > I think that controls should initially dispatch MIP events so as to > make this use case possible. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 96
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#evt-versionException The property here is called "errorinformation", but the equivalent property in the previous section is called "error-message" (and all other sections seem to use a hyphen too). I propose it should be called "error-information" Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group agrees, and the change is available in the editor's draft. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#evt-versionException > > The property here is called "errorinformation", but the equivalent > property in the previous section is called "error-message" (and all other > sections seem to use a hyphen too). > > I propose it should be called "error-information" > > Steven > >
PROBLEM ID: 60
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#evt-output-error Should be moved to section 4.5 Error Indications In the sentence: "Dispatched by the processor immediately after the first failure of an output to render or update the rendition of content." What does "first" mean here? The first failure of any output? The first failure of each output? The first failure of each invocation of an output? It is not clear here what causes such a failure. Please link to 8.1.5 The output Element http://www.w3.org/TR/xforms11/#ui-output
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group accepted your last call comment, and the changes you requested are now available in the editor's draft available from the working group home page. It was necessary to tighten up some language in xforms-refresh so that it could be made clear that the occurrence of the event corresponded to failures that occur either on control creation or during refresh. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#evt-output-error > > Should be moved to section 4.5 Error Indications > > In the sentence: "Dispatched by the processor immediately after the > first failure of an output to render or update the rendition of > content." > > What does "first" mean here? The first failure of any output? The > first failure of each output? The first failure of each invocation of > an output? > > It is not clear here what causes such a failure. Please link to 8.1.5 > The output Element http://www.w3.org/TR/xforms11/#ui-output > >
PROBLEM ID: 61
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#evt-versionException Lacks a description
PROBLEM ID: 59
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#evt-submit-error Should be moved to section 4.5 Error Indications
Messages in this directory have been submitted to the system, but have not yet been evaluated.
PROBLEM ID: 102
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#model-prop-required "An XForms Processor may provide an indication that a form control is required, and may provide immediate feedback, including limiting navigation." While the readonly property says: "Form controls bound to instance data with the readonly model item property should indicate that entering or changing the value is not allowed." Relevant says: "In general, when true, associated form controls should be made visible. When false, associated form controls (and any children) and group and switch elements (including content) must be made unavailable, removed from the navigation order, and not allowed focus." The type and constraint MIPs say nothing about display (though there is probably something somewhere). 1. I think that the processor SHOULD provide information that a value is required in bound controls, in the same way as readonly says. 2. I think we should say something in the type and constraint MIPs, even if it's only a cross-reference. Steven
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Steven, We accepted your comments, and the spec will be updated accordingly. Regards, Nick Van den Bleeken > > http://www.w3.org/TR/xforms11/#model-prop-required > > "An XForms Processor may provide an indication that a form control is > required, and may provide immediate feedback, including limiting > navigation." > > While the readonly property says: > "Form controls bound to instance data with the readonly model item > property should indicate that entering or changing the value is not > allowed." > > Relevant says: > "In general, when true, associated form controls should be made visible. > When false, associated form controls (and any children) and group and > switch elements (including content) must be made unavailable, removed from > the navigation order, and not allowed focus." > > The type and constraint MIPs say nothing about display (though there is > probably something somewhere). > > 1. I think that the processor SHOULD provide information that a value is > required in bound controls, in the same way as readonly says. > > 2. I think we should say something in the type and constraint MIPs, even > if it's only a cross-reference. > > Steven > >
PROBLEM ID: 176
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 001AF15688257331_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM ----- Vlad Trakhtenberg/CanWest/IBM@IBMCA Sent by: www-forms-request@w3.org 08/04/2007 12:00 PM To www-forms-editor@w3.org cc www-forms@w3.org Subject when and how readonly MIP prevents data mutations Dear WG & Editor, I think the XForms readonly model item property is not defined in clear enough terms, esp. from the implementer's perspective. This lack of clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: Description: describes whether the value (!) is restricted from changing. (*) ... Then it follows: When evaluating to true, this model item property indicates that the XForms Processor should not allow any (!) changes to the bound instance data node. (**) In addition to restricting value changes, the readonly model item property provides a hint to the XForms user interface. Form controls bound to instance data with the readonly model item property should indicate that entering or changing the value is not allowed.(***) 1. Let's assume for a moment that an implementer should interpret (**) literally, this would mean that all calculate properties shall by default fail to change their respective instance nodes since for all the said nodes the readonly property will evaluate to true() by default. 2. Again assuming that the readonly node is totally immutable suggests that there are omissions or in the sections of the draft describing processing of the insert, delete, setvalue, and reset actions as well as submissions with replace="instance" or "text". Notably, there is no defined response if an attempt is made to change 'readonly' node by these means. 3. A side issue with (**) is that if an application is to use instance document via exposed DOM interfaces [getInstanceDocument()] it is expected to use DOM methods to possibly mutate it (that's why the rebuild(), etc are for) and since there is no DOM access to MIPs there is no way the application can honour the 'no-changes-to-readonly-nodes' rule. To sum it up, I can clearly see how useful and mostly straight forward (with the possible exception of 'readonly' trigger & submit.) is the application of the readonly property by Form controls (as in ***) However, in my opinion, the use of this property to restrict data mutations by other means is either misplaced or underspec'd. Best regards, Vlad Trakhtenberg --=_alternative 001AF15688257331_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif"><br> </font> <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Vlad Trakhtenberg/CanWest/IBM@IBMCA</b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font> <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif">www-forms@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">when and how readonly MIP prevents data mutations</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2 face="sans-serif"><br> Dear WG & Editor,</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> I think the XForms <b>readonly</b> model item property is not defined in clear enough terms, esp. from the implementer's perspective. This lack of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b> says: </font> <p><font size=3 face="sans-serif">Description: describes whether the <i>value</i> (!) is restricted from changing. (*)</font><font size=2 face="sans-serif"><br> ...<br> Then it follows:</font><font size=3> </font> <p><font size=3 face="sans-serif">When evaluating to true, this model item property indicates that the XForms Processor should not allow <i>any</i> (!) changes to the bound instance data node. (**)</font><font size=3> </font> <p><font size=3 face="sans-serif"><i>In addition</i> to restricting <i>value</i> changes, the readonly model item property provides a hint to the XForms user interface. Form controls bound to instance data with the readonly model item property should indicate that entering or changing the value is not allowed.(***)</font><font size=3> <br> <br> </font><font size=2 face="sans-serif"><br> 1. Let's assume for a moment that an implementer should interpret (**) literally, this would mean that all <b>calculate</b> properties shall by default fail to change their respective instance nodes since for all the said nodes the <b>readonly</b> property will evaluate to true() by default.</font><font size=3> </font><font size=2 face="sans-serif"><br> 2. Again assuming that the readonly node is totally immutable suggests that there are omissions or in the sections of the draft describing processing of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset </b>actions as well as submissions with <b>replace</b>="instance" or "text". Notably, there is no defined response if an attempt is made to change 'readonly' node by these means. <br> 3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font size=2 face="sans-serif"> is that if an application is to use instance document via exposed DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font size=2 face="sans-serif">it is expected to use DOM methods to possibly mutate it (that's why the rebuild(), etc are for) and since there is no DOM access to MIPs there is no way the application can honour the 'no-changes-to-readonly-nodes' rule.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> To sum it up, I can clearly see how useful and mostly straight forward (with the possible exception of 'readonly' trigger & submit.) is the application of the <b>readonly</b> property by Form controls (as in ***) However, in my opinion, the use of this property to restrict data mutations by other means is either misplaced or underspec'd.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br> Vlad Trakhtenberg</font><font size=3> </font><font size=2 face="sans-serif"><br> </font><font size=3> </font> --=_alternative 001AF15688257331_=--
FOLLOWUP 1:
From: John Boyer <xforms-issues@aptest.com> Hi Vlad, The working group agrees that the applicability of readonly is underspecified. The working group decided that readonly is an inviolate property of the model. This means that form controls cannot modify readonly nodes to which they are bound, of course, but it also means that XForms actions and submissions have restrictions as well. Specifically, neither setvalue nor text replacement submission can modify a readonly node and neither insert, delete nor instance replacement submission can modify a node whose parent is readonly. The reason for checking the parent node in the case of insert is clear: the node could not be readonly until after it is inserted. In the case of delete and instance replacement, the view is that node deletion does not change the node. However, node insertion or deletion (and hence replacement) does change the *conten* or attribute axis of the parent, which is what readonly is intended to protect. The editor's draft available from the working group page has been updated to reflect these substantive changes to XForms 1.1. Please let us know if you have any further concerns regarding the changes made. Thanks, John Boyer > This is a multipart message in MIME format. > --=_alternative 001AF15688257331_= > Content-Type: text/plain; charset="US-ASCII" > > ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM ----- > > Vlad Trakhtenberg/CanWest/IBM@IBMCA > Sent by: www-forms-request@w3.org > 08/04/2007 12:00 PM > > To > www-forms-editor@w3.org > cc > www-forms@w3.org > Subject > when and how readonly MIP prevents data mutations > > > > > > > > Dear WG & Editor, > > I think the XForms readonly model item property is not defined in clear > enough terms, esp. from the implementer's perspective. This lack of > clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: > Description: describes whether the value (!) is restricted from changing. > (*) > ... > Then it follows: > When evaluating to true, this model item property indicates that the > XForms Processor should not allow any (!) changes to the bound instance > data node. (**) > In addition to restricting value changes, the readonly model item property > provides a hint to the XForms user interface. Form controls bound to > instance data with the readonly model item property should indicate that > entering or changing the value is not allowed.(***) > > > 1. Let's assume for a moment that an implementer should interpret (**) > literally, this would mean that all calculate properties shall by default > fail to change their respective instance nodes since for all the said > nodes the readonly property will evaluate to true() by default. > 2. Again assuming that the readonly node is totally immutable suggests > that there are omissions or in the sections of the draft describing > processing of the insert, delete, setvalue, and reset actions as well as > submissions with replace="instance" or "text". Notably, there is no > defined response if an attempt is made to change 'readonly' node by these > means. > 3. A side issue with (**) is that if an application is to use instance > document via exposed DOM interfaces [getInstanceDocument()] it is > expected to use DOM methods to possibly mutate it (that's why the > rebuild(), etc are for) and since there is no DOM access to MIPs there is > no way the application can honour the 'no-changes-to-readonly-nodes' rule. > > > To sum it up, I can clearly see how useful and mostly straight forward > (with the possible exception of 'readonly' trigger & submit.) is the > application of the readonly property by Form controls (as in ***) However, > in my opinion, the use of this property to restrict data mutations by > other means is either misplaced or underspec'd. > > Best regards, > Vlad Trakhtenberg > > --=_alternative 001AF15688257331_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=2 face="sans-serif"><br> > </font> > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>Vlad > Trakhtenberg/CanWest/IBM@IBMCA</b> > </font> > <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font> > <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td><font size=1 face="sans-serif">www-forms@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">when and how readonly MIP prevents data > mutations</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><font size=2 face="sans-serif"><br> > Dear WG & Editor,</font><font size=3> <br> > </font><font size=2 face="sans-serif"><br> > I think the XForms <b>readonly</b> model item property is not defined in > clear enough terms, esp. from the implementer's perspective. This lack > of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b> > says: </font> > <p><font size=3 face="sans-serif">Description: describes whether the > <i>value</i> > (!) is restricted from changing. (*)</font><font size=2 face="sans-serif"><br> >     ...<br> > Then it follows:</font><font size=3> </font> > <p><font size=3 face="sans-serif">When evaluating to true, this model item > property indicates that the XForms Processor should not allow <i>any</i> > (!) changes to the bound instance data node. (**)</font><font size=3> </font> > <p><font size=3 face="sans-serif"><i>In addition</i> to restricting <i>value</i> > changes, the readonly model item property provides a hint to the XForms > user interface. Form controls bound to instance data with the readonly > model item property should indicate that entering or changing the value > is not allowed.(***)</font><font size=3> <br> > <br> > </font><font size=2 face="sans-serif"><br> > 1. Let's assume for a moment that an implementer should interpret (**) > literally, this would mean that all <b>calculate</b> properties shall by > default fail to change their respective instance nodes since for all the > said nodes the <b>readonly</b> property will evaluate to true() by > default.</font><font size=3> > </font><font size=2 face="sans-serif"><br> > 2.  Again assuming that the readonly node is totally immutable suggests > that there are omissions or in the sections of the draft describing processing > of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset </b>actions > as well as submissions with <b>replace</b>="instance" or > "text". > Notably, there is no defined response if an attempt is made to change 'readonly' > node by these means. <br> > 3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font > size=2 face="sans-serif"> > is that if an application is to use instance document  via exposed > DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font size=2 > face="sans-serif">it > is expected to use DOM methods to possibly mutate it (that's why the rebuild(), > etc are for) and since there is no DOM access to MIPs there is no way the > application can honour the 'no-changes-to-readonly-nodes' rule.</font><font > size=3> > <br> > </font><font size=2 face="sans-serif"><br> > To sum it up, I can clearly see how useful and mostly straight forward > (with the possible exception of 'readonly' trigger & submit.) is the > application of the <b>readonly</b> property by Form controls (as in ***) > However, in my opinion, the use of this property to restrict data mutations > by other means is either misplaced or underspec'd.</font><font size=3> > <br> > </font><font size=2 face="sans-serif"><br> > Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br> > Vlad Trakhtenberg</font><font size=3> </font><font size=2 face="sans-serif"><br> > </font><font size=3> </font> > --=_alternative 001AF15688257331_=-- > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Vlad, The working group agrees that the applicability of readonly is underspecified. The working group decided that readonly is an inviolate property of the model. This means that form controls cannot modify readonly nodes to which they are bound, of course, but it also means that XForms actions and submissions have restrictions as well. Specifically, neither setvalue nor text replacement submission can modify a readonly node and neither insert, delete nor instance replacement submission can modify a node whose parent is readonly. The reason for checking the parent node in the case of insert is clear: the node could not be readonly until after it is inserted. In the case of delete and instance replacement, the view is that node deletion does not change the node. However, node insertion or deletion (and hence replacement) does change the *conten* or attribute axis of the parent, which is what readonly is intended to protect. The editor's draft available from the working group page has been updated to reflect these substantive changes to XForms 1.1. Please let us know if you have any further concerns regarding the changes made. Thanks, John Boyer > This is a multipart message in MIME format. > --=_alternative 001AF15688257331_= > Content-Type: text/plain; charset="US-ASCII" > > ----- Forwarded by John Boyer/CanWest/IBM on 08/07/2007 09:53 PM ----- > > Vlad Trakhtenberg/CanWest/IBM@IBMCA > Sent by: www-forms-request@w3.org > 08/04/2007 12:00 PM > > To > www-forms-editor@w3.org > cc > www-forms@w3.org > Subject > when and how readonly MIP prevents data mutations > > > > > > > > Dear WG & Editor, > > I think the XForms readonly model item property is not defined in clear > enough terms, esp. from the implementer's perspective. This lack of > clarity persists in the current XForms 1.1 draft. The section 6.1.2 says: > Description: describes whether the value (!) is restricted from changing. > (*) > ... > Then it follows: > When evaluating to true, this model item property indicates that the > XForms Processor should not allow any (!) changes to the bound instance > data node. (**) > In addition to restricting value changes, the readonly model item property > provides a hint to the XForms user interface. Form controls bound to > instance data with the readonly model item property should indicate that > entering or changing the value is not allowed.(***) > > > 1. Let's assume for a moment that an implementer should interpret (**) > literally, this would mean that all calculate properties shall by default > fail to change their respective instance nodes since for all the said > nodes the readonly property will evaluate to true() by default. > 2. Again assuming that the readonly node is totally immutable suggests > that there are omissions or in the sections of the draft describing > processing of the insert, delete, setvalue, and reset actions as well as > submissions with replace="instance" or "text". Notably, there is no > defined response if an attempt is made to change 'readonly' node by these > means. > 3. A side issue with (**) is that if an application is to use instance > document via exposed DOM interfaces [getInstanceDocument()] it is > expected to use DOM methods to possibly mutate it (that's why the > rebuild(), etc are for) and since there is no DOM access to MIPs there is > no way the application can honour the 'no-changes-to-readonly-nodes' rule. > > > To sum it up, I can clearly see how useful and mostly straight forward > (with the possible exception of 'readonly' trigger & submit.) is the > application of the readonly property by Form controls (as in ***) However, > in my opinion, the use of this property to restrict data mutations by > other means is either misplaced or underspec'd. > > Best regards, > Vlad Trakhtenberg > > --=_alternative 001AF15688257331_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=2 face="sans-serif"><br> > </font> > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 08/07/2007 09:53 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>Vlad > Trakhtenberg/CanWest/IBM@IBMCA</b> > </font> > <br><font size=1 face="sans-serif">Sent by: www-forms-request@w3.org</font> > <p><font size=1 face="sans-serif">08/04/2007 12:00 PM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td><font size=1 face="sans-serif">www-forms@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">when and how readonly MIP prevents data > mutations</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><font size=2 face="sans-serif"><br> > Dear WG & Editor,</font><font size=3> <br> > </font><font size=2 face="sans-serif"><br> > I think the XForms <b>readonly</b> model item property is not defined in > clear enough terms, esp. from the implementer's perspective. This lack > of clarity persists in the current XForms 1.1 draft. The section <b>6.1.2</b> > says: </font> > <p><font size=3 face="sans-serif">Description: describes whether the > <i>value</i> > (!) is restricted from changing. (*)</font><font size=2 face="sans-serif"><br> >     ...<br> > Then it follows:</font><font size=3> </font> > <p><font size=3 face="sans-serif">When evaluating to true, this model item > property indicates that the XForms Processor should not allow <i>any</i> > (!) changes to the bound instance data node. (**)</font><font size=3> </font> > <p><font size=3 face="sans-serif"><i>In addition</i> to restricting <i>value</i> > changes, the readonly model item property provides a hint to the XForms > user interface. Form controls bound to instance data with the readonly > model item property should indicate that entering or changing the value > is not allowed.(***)</font><font size=3> <br> > <br> > </font><font size=2 face="sans-serif"><br> > 1. Let's assume for a moment that an implementer should interpret (**) > literally, this would mean that all <b>calculate</b> properties shall by > default fail to change their respective instance nodes since for all the > said nodes the <b>readonly</b> property will evaluate to true() by > default.</font><font size=3> > </font><font size=2 face="sans-serif"><br> > 2.  Again assuming that the readonly node is totally immutable suggests > that there are omissions or in the sections of the draft describing processing > of the <b>insert</b>, <b>delete</b>, <b>setvalue</b>, and <b>reset </b>actions > as well as submissions with <b>replace</b>="instance" or > "text". > Notably, there is no defined response if an attempt is made to change 'readonly' > node by these means. <br> > 3. A side issue with </font><font size=3 face="sans-serif">(**)</font><font > size=2 face="sans-serif"> > is that if an application is to use instance document  via exposed > DOM interfaces </font><font size=3>[getInstanceDocument()] </font><font size=2 > face="sans-serif">it > is expected to use DOM methods to possibly mutate it (that's why the rebuild(), > etc are for) and since there is no DOM access to MIPs there is no way the > application can honour the 'no-changes-to-readonly-nodes' rule.</font><font > size=3> > <br> > </font><font size=2 face="sans-serif"><br> > To sum it up, I can clearly see how useful and mostly straight forward > (with the possible exception of 'readonly' trigger & submit.) is the > application of the <b>readonly</b> property by Form controls (as in ***) > However, in my opinion, the use of this property to restrict data mutations > by other means is either misplaced or underspec'd.</font><font size=3> > <br> > </font><font size=2 face="sans-serif"><br> > Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br> > Vlad Trakhtenberg</font><font size=3> </font><font size=2 face="sans-serif"><br> > </font><font size=3> </font> > --=_alternative 001AF15688257331_=-- > >
PROBLEM ID: 82
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, If I understand sections "4.3.5 The xforms-revalidate Event" and "6.1.1 The type Property" of XForms 1.1, XForms only considers datatypes during revalidation. A few questions then: 1. Does this mean that in XForms, we never perform full structural validation, even before submission? If so, where is this specified? 2. 6.1.1 says "The type model item property is not applied to instance nodes that contain child elements.". However, controls bound to elements store and retrieve data as the first child text node of the element, see 8.1.1: "returns the string-value of the first text child node" and 10.8: "the first text node is replaced with one corresponding to the new value" Wouldn't it make sense, for consistency, to say that type validation applies to the first child text node (empty string if none) of an element? I don't have a very strong opinion on this. Maybe doing so would violate expectations of schema validation? But here, we are only using datatypes to validate captured data, not validating structure, so I am not sure if this is a concern. I am wondering if this was considered at all. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, 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). This has been a long-standing problem that has now been fixed. 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. There are several problems with binding to the first text node, most notably the following: <a></a> has no first text node child in xpath data model, yet a UI control should not fail to bind to a node just because it is empty <b>1<!-- -->B</b> would show '1' to the user but be schema invalid as integer content because 1B is considered In short, the UI bindings should bind to the content of the referenced node, not its first text node child for consistency. The spec changes needed to implement this behavioral change have been made in the editor's draft available from the working group home page. Best regards, John Boyer > > All, > > If I understand sections "4.3.5 The xforms-revalidate Event" and > "6.1.1 The type Property" of XForms 1.1, XForms only considers > datatypes during revalidation. > > A few questions then: > > 1. Does this mean that in XForms, we never perform full structural > validation, even before submission? If so, where is this specified? > > 2. 6.1.1 says "The type model item property is not applied to instance > nodes that contain child elements.". However, controls bound to > elements store and retrieve data as the first child text node of > the element, see 8.1.1: > > "returns the string-value of the first text child node" > > and 10.8: > > "the first text node is replaced with one corresponding to the > new value" > > Wouldn't it make sense, for consistency, to say that type > validation applies to the first child text node (empty string if > none) of an element? > > I don't have a very strong opinion on this. Maybe doing so would > violate expectations of schema validation? But here, we are only > using datatypes to validate captured data, not validating > structure, so I am not sure if this is a concern. > > I am wondering if this was considered at all. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 100
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#model-xformsconstraints "It is an error to attempt to set a model item property twice on the same node. The details of this process are given at 4.2.1 The xforms-model-construct Event. (http://www.w3.org/TR/xforms11/#evt-modelConstruct)" Except that it isn't (has been deleted) Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The text got moved to rebuild, so an editorial fix will be done. Thanks, The Forms WG > > http://www.w3.org/TR/xforms11/#model-xformsconstraints > > "It is an error to attempt to set a model item property twice on the same > node. The details of this process are given at 4.2.1 The > xforms-model-construct Event. > (http://www.w3.org/TR/xforms11/#evt-modelConstruct)" > > Except that it isn't (has been deleted) > > Steven > >
PROBLEM ID: 99
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#model-xformsconstraints "It is an error to attempt to set a model item property twice on the same node." I thought we had agreed to relax this. I remember discussing it for constraints, but as long as MIPs don't confliuct, is it a problem? Steven
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, We did agree to do it in a future version, but not to do it in XForms 1.1. We added to the future features. Best wishes, Nick Van den Bleeken For the Forms WG > > http://www.w3.org/TR/xforms11/#model-xformsconstraints > > "It is an error to attempt to set a model item property twice on the same > node." > > I thought we had agreed to relax this. I remember discussing it for > constraints, but as long as MIPs don't confliuct, is it a problem? > > Steven > >
PROBLEM ID: 101
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#model-prop-readOnly "Default Value: false(), unless a calculate property is specified, then true()." => "Default Value: false(), unless a calculate property is specified for the value, then true()." Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Agreed that we have steadily been improving the spec to ensure that the calculate attribute calculates the value property, rather than having a calculate property that is somehow distinct from the value of the node being calculated. To that end, your suggestion was accepted but modified to be even clearer. In the editor's draft available from the Forms WG website, it now says "... unless a calculate is specified for the value property..." Therefore, your suggested words have been included. Please let us know if you have any further concerns about this issue. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#model-prop-readOnly > > "Default Value: false(), unless a calculate property is specified, then > true()." > > => > > "Default Value: false(), unless a calculate property is specified for the > value, then true()." > > Steven > >
PROBLEM ID: 45
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Disagree
ORIGINAL MESSAGE:
From: "David Landwehr" <david.landwehr@picoforms.com> Having the following: <xf:model> <xf:instance> <data xmlns="">value</data> </xf:instance> <xf:bind nodeset="." readonly="false()" calculate="1"/> </xf:model> It is not spelled out in the specification that it is possible to override the default state when it has a calculate on it. The default value is true() when the node has a calculate on it. On the other side it is not specified that it is not allowed. I think it should not be allowed since it is not clear when the value will be recalculated because a node cannot take itself as dependent. E.g. an insert or delete will recalculate the value even if the user has updated the value (this must also happen if an insert happens in another instance). This could be a problem for implementation which isolates the creating of dependencies between instances. Best regards, David
FOLLOWUP 1:
From: David Landwehr <david.landwehr@picoforms.com> The decission is not acceptable as I asked for a different resolution. For big forms optimization of the master dependency graph is of great importance and this resolution detroys the general optimization. I will read the minuts from the f2f to see on what ground my proposal was disregarded and ask for this to be taken into review again. /David John Boyer skrev: > We agree it was unclear, but we find that calculate merely defaults readonly to > true, and that it can be set to false, and that there are use cases, namely > default value. We tested the use case and found it works. We changed the note in > 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate] > and put an example in MIP for readonly [ > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly] > > Please let us know if this resolution is acceptable. > > Thank you, > The Forms Working Group > > >> Having the following: >> <xf:model> >> <xf:instance> >> <data xmlns="">value</data> >> </xf:instance> >> <xf:bind nodeset="." readonly="false()" calculate="1"/> >> </xf:model> >> >> It is not spelled out in the specification that it is possible to >> override the default state when it has a calculate on it. The default >> value is true() when the node has a calculate on it. On the other side >> it is not specified that it is not allowed. I think it should not be >> allowed since it is not clear when the value will be recalculated >> because a node cannot take itself as dependent. E.g. an insert or delete >> will recalculate the value even if the user has updated the value (this >> must also happen if an insert happens in another instance). This could >> be a problem for implementation which isolates the creating of >> dependencies between instances. >> >> Best regards, >> David >> >> >>
FOLLOWUP 2:
From: David Landwehr <david.landwehr@picoforms.com> I have read through the minutes and it seems you don't even consider my request. The statement by John "I don't think you can do that kind of isolation." clearly displays the ignorance from which the decissions are made in the working group. I accept the resolution simply because I give up. /David John Boyer skrev: > We agree it was unclear, but we find that calculate merely defaults readonly to > true, and that it can be set to false, and that there are use cases, namely > default value. We tested the use case and found it works. We changed the note in > 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate] > and put an example in MIP for readonly [ > http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly] > > Please let us know if this resolution is acceptable. > > Thank you, > The Forms Working Group > > >> Having the following: >> <xf:model> >> <xf:instance> >> <data xmlns="">value</data> >> </xf:instance> >> <xf:bind nodeset="." readonly="false()" calculate="1"/> >> </xf:model> >> >> It is not spelled out in the specification that it is possible to >> override the default state when it has a calculate on it. The default >> value is true() when the node has a calculate on it. On the other side >> it is not specified that it is not allowed. I think it should not be >> allowed since it is not clear when the value will be recalculated >> because a node cannot take itself as dependent. E.g. an insert or delete >> will recalculate the value even if the user has updated the value (this >> must also happen if an insert happens in another instance). This could >> be a problem for implementation which isolates the creating of >> dependencies between instances. >> >> Best regards, >> David >> >> >>
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> We agree it was unclear, but we find that calculate merely defaults readonly to true, and that it can be set to false, and that there are use cases, namely default value. We tested the use case and found it works. We changed the note in 4.3.6 [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-recalculate] and put an example in MIP for readonly [ http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-prop-readOnly] Please let us know if this resolution is acceptable. Thank you, The Forms Working Group > > > Having the following: > <xf:model> > <xf:instance> > <data xmlns="">value</data> > </xf:instance> > <xf:bind nodeset="." readonly="false()" calculate="1"/> > </xf:model> > > It is not spelled out in the specification that it is possible to > override the default state when it has a calculate on it. The default > value is true() when the node has a calculate on it. On the other side > it is not specified that it is not allowed. I think it should not be > allowed since it is not clear when the value will be recalculated > because a node cannot take itself as dependent. E.g. an insert or delete > will recalculate the value even if the user has updated the value (this > must also happen if an insert happens in another instance). This could > be a problem for implementation which isolates the creating of > dependencies between instances. > > Best regards, > David > >
PROBLEM ID: 53
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> Everywhere an attribute is marked Optional, please say what the default value is. Please say everywhere what the type of attributes are. For instance instance@resource. Please list the possible values when they are of an enumeration. Please say everywhere if an XPath expression is required to evaluate to a particula type (eg insert@at must be a number or integer).
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Steven, The editor's draft available from the working group home page now contains corrections to address this last call issue. The enumerations and datatypes of attributes appear in the content model tables at the beginnings of the chapters. In the cases of XPath expression results, the expected return type was identified (e.g. string, numeric). The bulk of the issues here seemed to be in Chapter 10 Actions. The default values for optional attributes are now also identified. Most already were, but the bulk of the issues seemed to arise in Chapter 11 Submissions for attributes that were analogous to those found in XSLT. Please let us know if you have any further concerns about this issue. Thanks, John Boyer > > Everywhere an attribute is marked Optional, please say what the > default value is. > > Please say everywhere what the type of attributes are. For instance > instance@resource. Please list the possible values when they are of an > enumeration. > > Please say everywhere if an XPath expression is required to evaluate > to a particula type (eg insert@at must be a number or integer). > > >
PROBLEM ID: 119
STATE: Suspended
EDIT: None
RESOLUTION: Defer
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Yves Savourel" <ysavourel@translate.com> --- 1) Is the WG planning to provide an ITS Rule file along with the specification (e.g. as a non-normative appendix)? [[ Just in case if you are not familiar with ITS: It is a Proposed Recommendation (planning to go as Recommendation next week) that define a set of elements and attributes that provide "read-to-go" internationalization features. See also: http://www.w3.org/TR/its/ ]] For instance, when I look at the second XML code sample in section 2.1, I see several elements containing text: <label> and <value>. Most, if not all, localization tools, as well as ITS, assume element content is translatable. However in this case I'm guessing that <value>Cash</Cash> is not. While this is fine because tools have ways to specify an element should not be translated, it is very often quite difficult no know *which elements* is like that. Having a list of elements that are non-translatable (or conversely if there are more non-translatable than translatable elements) would help a lot. This list could be expressed using ITS rules. This way all user of translation tools (or other language-related applications such as spell-checker, machine-translation engines, etc) could look up that set of rules and process accordingly. In this example it would be as simple as: <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:translateRule selector="//value" translate="no"/> </its:rules>
FOLLOWUP 1:
From: "Yves Savourel" <ysavourel@translate.com> Hi Ulrich, > An ITS rule file is not a normative part of the recommendation > and we would be happy to provide some meeting time to help > I18N WG create it, but we do not have the resources to create it. We will try to find the time to do it and get back to you to see if what we did make sense. One question: Do you have a set of XForm files we could use to test it? Something that covers as many of the Xform elements/attributes as possible would be ideal. Thanks -yves -----Original Message----- From: Ulrich Nicolas Lissé [mailto:xforms-issues@mn.aptest.com] Sent: Wednesday, June 13, 2007 2:25 PM To: ysavourel@translate.com Cc: www-forms-editor@w3.org Subject: Re: ITS Rule file (PR#119) > --- 1) Is the WG planning to provide an ITS Rule file along with the > specification (e.g. as a non-normative appendix)? > > [[ Just in case if you are not familiar with ITS: It is a Proposed > Recommendation (planning to go as Recommendation next week) that > define a set of elements and attributes that provide "read-to-go" > internationalization features. See also: http://www.w3.org/TR/its/ ]] > > For instance, when I look at the second XML code sample in section > 2.1, I see several elements containing text: <label> and <value>. > Most, if not all, localization tools, as well as ITS, assume element > content is translatable. However in this case I'm guessing that > <value>Cash</Cash> is not. > > While this is fine because tools have ways to specify an element > should not be translated, it is very often quite difficult no know > *which elements* is like that. Having a list of elements that are > non-translatable (or conversely if there are more non-translatable > than translatable elements) would help a lot. > > This list could be expressed using ITS rules. This way all user of > translation tools (or other language-related applications such as > spell-checker, machine-translation engines, etc) could look up that > set of rules and process accordingly. In this example it would be as > simple as: > > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> > <its:translateRule selector="//value" translate="no"/> </its:rules> > > An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG create it, but we do not have the resources to create it. Regards, Ulrich Nicolas Lissé. For the Forms WG
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> > --- 1) Is the WG planning to provide an ITS Rule file along with the > specification (e.g. as a non-normative appendix)? > > [[ Just in case if you are not familiar with ITS: It is a Proposed > Recommendation (planning to go as Recommendation next week) that > define a set of elements and attributes that provide "read-to-go" > internationalization features. See also: http://www.w3.org/TR/its/ > ]] > > For instance, when I look at the second XML code sample in section 2.1, I > see several elements containing text: <label> and <value>. > Most, if not all, localization tools, as well as ITS, assume element > content is translatable. However in this case I'm guessing that > <value>Cash</Cash> is not. > > While this is fine because tools have ways to specify an element should > not be translated, it is very often quite difficult no know > *which elements* is like that. Having a list of elements that are > non-translatable (or conversely if there are more non-translatable > than translatable elements) would help a lot. > > This list could be expressed using ITS rules. This way all user of > translation tools (or other language-related applications such as > spell-checker, machine-translation engines, etc) could look up that set of > rules and process accordingly. In this example it would > be as simple as: > > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> > <its:translateRule selector="//value" translate="no"/> > </its:rules> > > An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG create it, but we do not have the resources to create it. Regards, Ulrich Nicolas Lissé. For the Forms WG
PROBLEM ID: 171
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 006D01A788257329_= Content-Type: text/plain; charset="US-ASCII" John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:49 PM ----- Guntis Ozols <guntiso@latnet.lv> Sent by: www-forms-editor-request@w3.org 07/08/2007 04:30 AM To www-forms-editor@w3.org cc Subject Add optional root element to schema to encourage SoC Xml requires root element and xforms schema does not define any, thus encouraging to tangle form with host language. At the moment, xforms are otherwise quite self sufficient. With root element, forms could be built, tested, and stored as valid xml without any irrelevant host language, then combined with separately managed host language representation(s) (styles) for these forms. PS. Please refer me to convincing info why keep current restriction if I do not know what I am talking about. Guntis --=_alternative 006D01A788257329_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----</font> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Guntis Ozols <guntiso@latnet.lv></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">07/08/2007 04:30 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">Add optional root element to schema to encourage SoC</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> Xml requires root element and xforms schema does not define any,<br> thus encouraging to tangle form with host language.<br> <br> At the moment, xforms are otherwise quite self sufficient.<br> <br> With root element, forms could be built, tested,<br> and stored as valid xml without any irrelevant host language,<br> then combined with separately managed host language<br> representation(s) (styles) for these forms.<br> <br> PS. Please refer me to convincing info why keep current<br> restriction if I do not know what I am talking about.<br> <br> Guntis<br> <br> <br> </font></tt> --=_alternative 006D01A788257329_=--
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Guntis, 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. Regards, Nick Van den Bleeken > This is a multipart message in MIME format. > --=_alternative 006D01A788257329_= > Content-Type: text/plain; charset="US-ASCII" > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > > > ----- Forwarded by John Boyer/CanWest/IBM on 07/31/2007 12:49 PM ----- > > Guntis Ozols <guntiso@latnet.lv> > Sent by: www-forms-editor-request@w3.org > 07/08/2007 04:30 AM > > To > www-forms-editor@w3.org > cc > > Subject > Add optional root element to schema to encourage SoC > > > > > > > > Xml requires root element and xforms schema does not define any, > thus encouraging to tangle form with host language. > > At the moment, xforms are otherwise quite self sufficient. > > With root element, forms could be built, tested, > and stored as valid xml without any irrelevant host language, > then combined with separately managed host language > representation(s) (styles) for these forms. > > PS. Please refer me to convincing info why keep current > restriction if I do not know what I am talking about. > > Guntis > > > > --=_alternative 006D01A788257329_= > Content-Type: text/html; charset="US-ASCII" > > > <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> > STSM: Lotus Forms Architect and Researcher<br> > Chair, W3C Forms Working Group<br> > Workplace, Portal and Collaboration Software<br> > IBM Victoria Software Lab<br> > E-Mail: boyerj@ca.ibm.com <br> > <br> > Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font > size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font > size=2 face="sans-serif"><br> > <br> > </font> > <br><font size=1 color=#800080 face="sans-serif">----- Forwarded by John > Boyer/CanWest/IBM on 07/31/2007 12:49 PM -----</font> > <br> > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>Guntis Ozols > <guntiso@latnet.lv></b> > </font> > <br><font size=1 face="sans-serif">Sent by: > www-forms-editor-request@w3.org</font> > <p><font size=1 face="sans-serif">07/08/2007 04:30 AM</font> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">Add optional root element to schema > to encourage SoC</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > Xml requires root element and xforms schema does not define any,<br> > thus encouraging to tangle form with host language.<br> > <br> > At the moment, xforms are otherwise quite self sufficient.<br> > <br> > With root element, forms could be built, tested,<br> > and stored as valid xml without any irrelevant host language,<br> > then combined with separately managed host language<br> > representation(s) (styles) for these forms.<br> > <br> > PS. Please refer me to convincing info why keep current<br> > restriction if I do not know what I am talking about.<br> > <br> > Guntis<br> > <br> > <br> > </font></tt> > --=_alternative 006D01A788257329_=-- > >
PROBLEM ID: 125
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> Change "XForms is not a free-standing document type, but is intended to be integrated into other markup languages, " To "XForms is not a free-standing document type, but is intended to be integrated into other markup languages as a compound document [see CDRF 1.0 ]. " Add to Appendix B References "CDRF 1.0 Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse Pajunen, Julien Quint, Daniel Applequist, 2007, W3C Working Draft available at http://www.w3.org/TR/CDR/" Rationale: Compound Document is the W3C term for a document that combines multiple formats.
FOLLOWUP 1:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear CDF WG, 1) This is only a working draft whose advancement we don't want to be tied to. 2) XForms is intended to be used with host languages even if they do not observe the compound document framework. Regards, Nick Van den Bleeken > Change > "XForms is not a free-standing document type, but is intended to be > integrated into other markup languages, " > To > "XForms is not a free-standing document type, but is intended to be > integrated into other markup languages as a compound document [see CDRF 1.0 > ]. " > Add to Appendix B References > "CDRF 1.0 > Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse > Pajunen, Julien Quint, Daniel Applequist, > 2007, W3C Working Draft available at http://www.w3.org/TR/CDR/" > Rationale: Compound Document is the W3C term for a document that combines > multiple formats. > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear CDF WG, 1) This is only a working draft whose advancement we don't want to be tied to. 2) XForms is intended to be used with host languages even if they do not observe the compound document framework. Regards, Nick Van den Bleeken > Change > "XForms is not a free-standing document type, but is intended to be > integrated into other markup languages, " > To > "XForms is not a free-standing document type, but is intended to be > integrated into other markup languages as a compound document [see CDRF 1.0 > ]. " > Add to Appendix B References > "CDRF 1.0 > Compound Document by Reference Framework 1.0, Timur Mehrvarz, Lasse > Pajunen, Julien Quint, Daniel Applequist, > 2007, W3C Working Draft available at http://www.w3.org/TR/CDR/" > Rationale: Compound Document is the W3C term for a document that combines > multiple formats. > >
PROBLEM ID: 126
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
We agreed to add ODF as example and to add an informative reference.
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> Change "such as XHTML or SVG. " To "such as XHTML, ODF [see ODF 1.1], or SVG. " Add to references "ODF 1.1 Open Document Format for Office Applications (OpenDocument) v1.1, Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11 Rationale: No where in the XForms 1.1 does it state that XForms must be included in whole. ODF uses some XForms elements and is an open standard so it should be acknowledged as a non-W3C example of using XForms as a compound document.
FOLLOWUP 1:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 005E0DE688257384_= Content-Type: text/plain; charset="US-ASCII" Hi Kevin, An informative reference for ODF 1.1 has been added to the XForms 1.1 specification. Please see the editor's draft available from the Forms WG homepage. Best regards, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer --=_alternative 005E0DE688257384_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Kevin,</font> <br> <br><font size=2 face="sans-serif">An informative reference for ODF 1.1 has been added to the XForms 1.1 specification. Please see the editor's draft available from the Forms WG homepage.</font> <br> <br><font size=2 face="sans-serif">Best regards,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> --=_alternative 005E0DE688257384_=--
FOLLOWUP 2:
From: Kevin E Kelly <Kevin.Kelly@us.ibm.com> --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593 Content-type: multipart/alternative; Boundary="1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593" --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable XForms WG: We find this a little confusing. You do already have references for XH= TML and SVG in your document, and you have both normative and informative references sections. Why not link ODF in the informative section? ALSO - Nick your emails to the member-cdf WG did not arrive to that mai= l list. Would you please resend them to member-cdf@w3.org from another e= mail address that is not blocked? CDF WG = From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> = = To: Kevin E Kelly/Raleigh/IBM@IBMUS = = Cc: member-cdf@w3.org, www-forms-editor@w3.org = = Date: 09/12/2007 06:45 AM = = Subject: Re: CDF03 - Abstract (Moved to Introduction) missing refe= rence to ODF. (PR#126) = Dear CDF WG, We agreed to add ODF as example but are not going to reference ODF, bec= ause we don't reference XHTML nor SVG. Regards, Nick Van den Bleeken > > Change > "such as XHTML or SVG. " > To > "such as XHTML, ODF [see ODF 1.1], or SVG. " > Add to references > "ODF 1.1 > Open Document Format for Office Applications (OpenDocument) v1= .1, > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Doffice#o= df11 > Rationale: No where in the XForms 1.1 does it state that XForms must = be > included in whole. ODF uses some XForms elements and is an open stan= dard > so it should be acknowledged as a non-W3C example of using XForms as = a > compound document. > > = --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p>XForms WG:<br> <br> We find this a little confusing. You do already have references for XH= TML and SVG in your document, and you have both normative and informati= ve references sections. Why not link ODF in the informative section? <= br> <br> ALSO - Nick your emails to the member-cdf WG did not arrive to that mai= l list. Would you please resend them to member-cdf@w3.org from another= email address that is not blocked?<br> <br> CDF WG<br> <br> <br> <img width=3D"16" height=3D"16" src=3D"cid:1__=3D0ABBF9F2DFD575938f9e8a= 93df938@us.ibm.com" border=3D"0" alt=3D"Inactive hide details for Nick = Van den Bleeken ---09/12/2007 06:45:32 AM---Dear CDF WG,"><font color=3D= "#424282">Nick Van den Bleeken ---09/12/2007 06:45:32 AM---Dear CDF WG,= </font><br> <br> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D= "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <font size=3D"2" color=3D"#5F5F5F">From:</font></td><td width=3D"100%">= <img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93= df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">Nick Van den Bleeken <xforms-issues@mn.aptest.com&g= t;</font></td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D= "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <font size=3D"2" color=3D"#5F5F5F">To:</font></td><td width=3D"100%"><i= mg width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93df= 938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">Kevin E Kelly/Raleigh/IBM@IBMUS</font></td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D= "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <font size=3D"2" color=3D"#5F5F5F">Cc:</font></td><td width=3D"100%" va= lign=3D"middle"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2= DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">member-cdf@w3.org, www-forms-editor@w3.org</font></td>= </tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D= "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <font size=3D"2" color=3D"#5F5F5F">Date:</font></td><td width=3D"100%">= <img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8a93= df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">09/12/2007 06:45 AM</font></td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"96" height=3D"1" src=3D= "cid:2__=3D0ABBF9F2DFD575938f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <font size=3D"2" color=3D"#5F5F5F">Subject:</font></td><td width=3D"100= %"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D0ABBF9F2DFD575938f9e8= a93df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">Re: CDF03 - Abstract (Moved to Introduction) missing r= eference to ODF. (PR#126)</font></td></tr> </table> <hr width=3D"100%" size=3D"2" align=3D"left" noshade style=3D"color:#80= 91A5; "><br> <br> <br> <tt>Dear CDF WG,<br> <br> We agreed to add ODF as example but are not going to reference ODF, bec= ause we<br> don't reference XHTML nor SVG. <br> <br> Regards,<br> <br> Nick Van den Bleeken<br> > <br> > Change<br> > "such as XHTML or SVG. "<br> > To<br> > "such as XHTML, ODF [see ODF 1.1], or SVG. "<br> > Add to references<br> > "ODF 1.1<br> > Open Document Format for Office Applica= tions (OpenDocument) v1.1,<br> > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available a= t<br> > </tt><tt><a href=3D"http://www.oasis-open.org/committees/tc_home.p= hp?wg_abbrev=3Doffice#odf11">http://www.oasis-open.org/committees/tc_ho= me.php?wg_abbrev=3Doffice#odf11</a></tt><tt><br> > Rationale: No where in the XForms 1.1 does it state that XForms mu= st be<br> > included in whole. ODF uses some XForms elements and is an o= pen standard<br> > so it should be acknowledged as a non-W3C example of using XForms = as a<br> > compound document.<br> > <br> > <br> </tt><br> </body></html>= --1__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593-- --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF9F2DFD575938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <2__=0ABBF9F2DFD575938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBF9F2DFD575938f9e8a93df938690918c0ABBF9F2DFD57593--
FOLLOWUP 3:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear CDF WG, We agreed to add ODF as example but are not going to reference ODF, because we don't reference XHTML nor SVG. Regards, Nick Van den Bleeken > > Change > "such as XHTML or SVG. " > To > "such as XHTML, ODF [see ODF 1.1], or SVG. " > Add to references > "ODF 1.1 > Open Document Format for Office Applications (OpenDocument) v1.1, > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11 > Rationale: No where in the XForms 1.1 does it state that XForms must be > included in whole. ODF uses some XForms elements and is an open standard > so it should be acknowledged as a non-W3C example of using XForms as a > compound document. > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear CDF WG, We agreed to add ODF as example but are not going to reference ODF, because we don't reference XHTML nor SVG. Regards, Nick Van den Bleeken > > Change > "such as XHTML or SVG. " > To > "such as XHTML, ODF [see ODF 1.1], or SVG. " > Add to references > "ODF 1.1 > Open Document Format for Office Applications (OpenDocument) v1.1, > Patrick Durusau, Micheal Brauer, Lars Oppermann, 2007, available at > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office#odf11 > Rationale: No where in the XForms 1.1 does it state that XForms must be > included in whole. ODF uses some XForms elements and is an open standard > so it should be acknowledged as a non-W3C example of using XForms as a > compound document. > >
PROBLEM ID: 9
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 3 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 2 Mention of Internationalization Comment: Internationalization Using XML 1.0 for instance data ensures that the submitted data is internationalization ready. We think that XForms should refer to XML 1.1 as well.
FOLLOWUP 1:
From: "Yves Savourel" <ysavourel@translate.com> Hi Ulrich, > An ITS rule file is not a normative part of the recommendation > and we would be happy to provide some meeting time to help > I18N WG create it, but we do not have the resources to create it. We will try to find the time to do it and get back to you to see if what we did make sense. One question: Do you have a set of XForm files we could use to test it? Something that covers as many of the Xform elements/attributes as possible would be ideal. Thanks -yves -----Original Message----- From: Ulrich Nicolas Lissé [mailto:xforms-issues@mn.aptest.com] Sent: Wednesday, June 13, 2007 2:25 PM To: ysavourel@translate.com Cc: www-forms-editor@w3.org Subject: Re: ITS Rule file (PR#119) > --- 1) Is the WG planning to provide an ITS Rule file along with the > specification (e.g. as a non-normative appendix)? > > [[ Just in case if you are not familiar with ITS: It is a Proposed > Recommendation (planning to go as Recommendation next week) that > define a set of elements and attributes that provide "read-to-go" > internationalization features. See also: http://www.w3.org/TR/its/ ]] > > For instance, when I look at the second XML code sample in section > 2.1, I see several elements containing text: <label> and <value>. > Most, if not all, localization tools, as well as ITS, assume element > content is translatable. However in this case I'm guessing that > <value>Cash</Cash> is not. > > While this is fine because tools have ways to specify an element > should not be translated, it is very often quite difficult no know > *which elements* is like that. Having a list of elements that are > non-translatable (or conversely if there are more non-translatable > than translatable elements) would help a lot. > > This list could be expressed using ITS rules. This way all user of > translation tools (or other language-related applications such as > spell-checker, machine-translation engines, etc) could look up that > set of rules and process accordingly. In this example it would be as > simple as: > > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> > <its:translateRule selector="//value" translate="no"/> </its:rules> > > An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG create it, but we do not have the resources to create it. Regards, Ulrich Nicolas Lissé. For the Forms WG
FOLLOWUP 2:
From: Felix Sasaki <fsasaki@w3.org> Thank you for your reply. I'm satisfied with your resolution. If you don't hear from other participants of the i18n core WG until Wednesday next week (19 Sept), please regard this issue as closed. Felix Nick Van den Bleeken wrote: > Felix, > > We defer the support of XML 1.1 to a later version of XForms, because XForms 1.1 > is based on XPath 1.0 and XPath 1.0 doesn't supports XML 1.1 > > We plan to support XPath 2.0 in XForms 2.0, and could consider supporting XML > 1.1 at that time. > > Regards, > > Nick Van den Bleeken > > >> Comment from the i18n review of: >> http://www.w3.org/TR/2007/WD-xforms11-20070222/ >> >> Comment 3 >> At http://www.w3.org/International/reviews/0704-xforms11/ >> Editorial/substantive: S >> Location in reviewed document: >> 2 >> Mention of Internationalization >> >> Comment: >> >> Internationalization Using XML 1.0 for instance data ensures that the >> submitted data is internationalization ready. >> We think that XForms should refer to XML 1.1 as well. >> >> >> >>
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> > --- 1) Is the WG planning to provide an ITS Rule file along with the > specification (e.g. as a non-normative appendix)? > > [[ Just in case if you are not familiar with ITS: It is a Proposed > Recommendation (planning to go as Recommendation next week) that > define a set of elements and attributes that provide "read-to-go" > internationalization features. See also: http://www.w3.org/TR/its/ > ]] > > For instance, when I look at the second XML code sample in section 2.1, I > see several elements containing text: <label> and <value>. > Most, if not all, localization tools, as well as ITS, assume element > content is translatable. However in this case I'm guessing that > <value>Cash</Cash> is not. > > While this is fine because tools have ways to specify an element should > not be translated, it is very often quite difficult no know > *which elements* is like that. Having a list of elements that are > non-translatable (or conversely if there are more non-translatable > than translatable elements) would help a lot. > > This list could be expressed using ITS rules. This way all user of > translation tools (or other language-related applications such as > spell-checker, machine-translation engines, etc) could look up that set of > rules and process accordingly. In this example it would > be as simple as: > > <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> > <its:translateRule selector="//value" translate="no"/> > </its:rules> > > An ITS rule file is not a normative part of the recommendation and we would be happy to provide some meeting time to help I18N WG create it, but we do not have the resources to create it. Regards, Ulrich Nicolas Lissé. For the Forms WG
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Felix, We defer the support of XML 1.1 to a later version of XForms, because XForms 1.1 is based on XPath 1.0 and XPath 1.0 doesn't supports XML 1.1 We plan to support XPath 2.0 in XForms 2.0, and could consider supporting XML 1.1 at that time. Regards, Nick Van den Bleeken > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 3 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 2 > Mention of Internationalization > > Comment: > > Internationalization Using XML 1.0 for instance data ensures that the > submitted data is internationalization ready. > We think that XForms should refer to XML 1.1 as well. > > >
PROBLEM ID: 162
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
We agreed to add a section to 1. About the XForms Specification
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222 1) I struggled to find the differences between 1.0 and 1.1, I guess I was expecting a brief intro section like: http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes I did find the diff marked version, which was a big help. Thanks, Steve Speicher IBM SWG, Software Standards
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Steve, We will update the spec accordingly, a section will be added that contains the improvements made in XForms 1.1 relative to XForms 1.0 Regards, Nick Van den Bleeken > > LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222 > > 1) I struggled to find the differences between 1.0 and 1.1, I guess I was > expecting a brief intro section like: > http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes > I did find the diff marked version, which was a big help. > > Thanks, > Steve Speicher > IBM SWG, Software Standards > >
PROBLEM ID: 17
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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".
ORIGINAL MESSAGE:
From: "Bjoern Hoehrmann" <derhoermi@gmx.net> Dear Forms Working Group, Please report to The Director my formal objection to the Working Group's decision to publish XForms 1.1 as Last Call Working Draft. The group made this decision in violation of the W3C Process, and due to its shocking history of W3C Process ignorance it would be difficult to assert that the document has received wide review and, therefore, advance the document under the rules of the W3C Process. Since the Forms Working Group has no interest in following the W3C Recommendation Track Process to develop XForms as demonstrated below, it is unclear to me that XForms development should continue in form of a W3C Working Group. However, if that is to be so, I recommend that instead of advancing XForms 1.1, the document is returned to the Working Group for further work and the group does not request publication of it as LCWD until after the group has, for all comments received since the publication of XForms 1.0 as LCWD, either formally addressed the comment or pub- lically documented sound rationale for not doing so, documented the results of this process, published updated non-LC drafts taking the results of this process into account, given reviewers sufficient time to review it, and put the XForms 1.0 errata into a form that satisfies the requirements of the W3C Process. It is important to note that this is not asking anything at all, had the Working Group not ignored the W3C Process for many years, this would be a zero-effort process. Similarily, the concern is not that a few things slipped through the cracks: the group has been repeatedly reminded of its failure the follow the W3C Process, and took little to no action to improve the situation. To give a few examples of my own experience with the group: Pre-REC comments on XForms 1.0 that I have never received a response to: http://lists.w3.org/Archives/Public/www-forms-editor/2003Aug/0002.html http://lists.w3.org/Archives/Public/www-forms-editor/2003Aug/0003.html An XForms 1.1 comment the group produced no meaningful response to: http://lists.w3.org/Archives/Public/www-forms-editor/2004Jan/0004.html A reminder to address the comment above (more reminders further down): http://lists.w3.org/Archives/Public/www-forms-editor/2004Aug/0001.html Discussions of the group's continued Process ignorance: http://lists.w3.org/Archives/Public/www-forms/2004Oct/0014.html http://lists.w3.org/Archives/Public/www-forms/2004Nov/0050.html A detailed review of how the group systematically ignored 1.0 comments: http://lists.w3.org/Archives/Member/process-issues/2006Feb/0001.html Reminders of the W3C Process requirements for errata maintenance: http://lists.w3.org/Archives/Public/www-forms/2006Jun/0043.html http://lists.w3.org/Archives/Public/www-forms/2006Sep/0109.html The group has not provided a response to any of these messages. As I already concluded in 2004, any attempt to cooperate with the group is a complete waste of effort. This view is shared, at least in part, by several other people with first hand experience with the Forms WG I talked to. As a consequence, many interested parties chose to not review the XForms 1.1 draft at all, let alone provide comments on it. Having received wide review is a pre-condition for advancement of the document to Candidate Recommendation status, and without the group following the the steps proposed above in full, it would be difficult to get to a point where interested parties do not actively refuse to review the document. Hence my recommendation. Thanks, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
PROBLEM ID: 15
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 10 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: Various Various comments on XForms 1.1 Comment: The Working Group endorses the coment sent by Yves Savourel http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html] , especially comment 1 (\"Is the WG planning to provide an ITS Rule file along with the specification (e.g. as a non-normative appendix)?\") Pleasekeep us in the loop during your discussion of the comments.
FOLLOWUP 1:
From: "Richard Ishida" <ishida@w3.org> John, Could you provide some links please? A quick look didn't reveal the location of the relevant information, and may have missed some important bits. Thanks, RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of John Boyer > Sent: 26 July 2007 19:40 > To: fsasaki@w3.org > Cc: www-forms-editor@w3.org; www-international@w3.org > Subject: Re: [XForms 1.1] i18n comment: Various comments on > XForms 1.1 (PR#15) > > > 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. > > Best regards, > John Boyer > > > > > Comment from the i18n review of: > > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > > > Comment 10 > > At http://www.w3.org/International/reviews/0704-xforms11/ > > Editorial/substantive: S > > Location in reviewed document: > > Various > > Various comments on XForms 1.1 > > > > Comment: > > The Working Group endorses the coment sent by Yves Savourel > > > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html > > > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm > > l] , especially comment 1 (\"Is the WG planning to provide > an ITS Rule > > file along with the specification (e.g. as a non-normative > > appendix)?\") Pleasekeep us in the loop during your > discussion of the > > comments. > > > > > > >
FOLLOWUP 2:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 0071744D88257329_= Content-Type: text/plain; charset="US-ASCII" http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=www-forms-editor Cheers, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Richard Ishida" <ishida@w3.org> Sent by: www-forms-editor-request@w3.org 07/30/2007 03:38 AM To "'John Boyer'" <xforms-issues@mn.aptest.com>, <fsasaki@w3.org> cc <www-forms-editor@w3.org>, <www-international@w3.org> Subject RE: [XForms 1.1] i18n comment: Various comments on XForms 1.1 (PR#15) John, Could you provide some links please? A quick look didn't reveal the location of the relevant information, and may have missed some important bits. Thanks, RI ============ Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/People/Ishida/ http://www.w3.org/International/ http://people.w3.org/rishida/blog/ http://www.flickr.com/photos/ishida/ > -----Original Message----- > From: www-international-request@w3.org > [mailto:www-international-request@w3.org] On Behalf Of John Boyer > Sent: 26 July 2007 19:40 > To: fsasaki@w3.org > Cc: www-forms-editor@w3.org; www-international@w3.org > Subject: Re: [XForms 1.1] i18n comment: Various comments on > XForms 1.1 (PR#15) > > > 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. > > Best regards, > John Boyer > > > > > Comment from the i18n review of: > > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > > > Comment 10 > > At http://www.w3.org/International/reviews/0704-xforms11/ > > Editorial/substantive: S > > Location in reviewed document: > > Various > > Various comments on XForms 1.1 > > > > Comment: > > The Working Group endorses the coment sent by Yves Savourel > > > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html > > > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm > > l] , especially comment 1 (\"Is the WG planning to provide > an ITS Rule > > file along with the specification (e.g. as a non-normative > > appendix)?\") Pleasekeep us in the loop during your > discussion of the > > comments. > > > > > > > --=_alternative 0071744D88257329_= Content-Type: text/html; charset="US-ASCII" <br><a href="http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=www-forms-editor"><font size=2 face="sans-serif">http://www.w3.org/Search/Mail/Public/search?keywords=ysavourel&hdr-1-name=subject&hdr-1-query=&index-grp=Public__FULL&index-type=t&type-index=www-forms-editor</font></a> <br> <br><font size=2 face="sans-serif">Cheers,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Richard Ishida" <ishida@w3.org></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">07/30/2007 03:38 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"'John Boyer'" <xforms-issues@mn.aptest.com>, <fsasaki@w3.org></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif"><www-forms-editor@w3.org>, <www-international@w3.org></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: [XForms 1.1] i18n comment: Various comments on XForms 1.1 (PR#15)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> John,<br> <br> Could you provide some links please? A quick look didn't reveal the<br> location of the relevant information, and may have missed some important<br> bits.<br> <br> Thanks,<br> RI<br> <br> ============<br> Richard Ishida<br> Internationalization Lead<br> W3C (World Wide Web Consortium)<br> <br> </font></tt><a href=http://www.w3.org/People/Ishida/><tt><font size=2>http://www.w3.org/People/Ishida/</font></tt></a><tt><font size=2><br> </font></tt><a href=http://www.w3.org/International/><tt><font size=2>http://www.w3.org/International/</font></tt></a><tt><font size=2><br> </font></tt><a href=http://people.w3.org/rishida/blog/><tt><font size=2>http://people.w3.org/rishida/blog/</font></tt></a><tt><font size=2><br> </font></tt><a href=http://www.flickr.com/photos/ishida/><tt><font size=2>http://www.flickr.com/photos/ishida/</font></tt></a><tt><font size=2><br> <br> <br> <br> > -----Original Message-----<br> > From: www-international-request@w3.org <br> > [</font></tt><a href="mailto:www-international-request@w3.org"><tt><font size=2>mailto:www-international-request@w3.org</font></tt></a><tt><font size=2>] On Behalf Of John Boyer<br> > Sent: 26 July 2007 19:40<br> > To: fsasaki@w3.org<br> > Cc: www-forms-editor@w3.org; www-international@w3.org<br> > Subject: Re: [XForms 1.1] i18n comment: Various comments on <br> > XForms 1.1 (PR#15)<br> > <br> > <br> > Answers for all last call comments attributed to Yves <br> > Savourel are now available in the www-forms-editor list <br> > archive and the results of spec changes now appear in the <br> > editor's draft available from the Forms WG website.<br> > <br> > Best regards,<br> > John Boyer<br> > <br> > > <br> > > Comment from the i18n review of:<br> > > </font></tt><a href="http://www.w3.org/TR/2007/WD-xforms11-20070222/"><tt><font size=2>http://www.w3.org/TR/2007/WD-xforms11-20070222/</font></tt></a><tt><font size=2><br> > > <br> > > Comment 10<br> > > At </font></tt><a href="http://www.w3.org/International/reviews/0704-xforms11/"><tt><font size=2>http://www.w3.org/International/reviews/0704-xforms11/</font></tt></a><tt><font size=2><br> > > Editorial/substantive: S<br> > > Location in reviewed document:<br> > > Various<br> > > Various comments on XForms 1.1<br> > > <br> > > Comment:<br> > > The Working Group endorses the coment sent by Yves Savourel <br> > > <br> > </font></tt><a href="http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html"><tt><font size=2>http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html</font></tt></a><tt><font size=2><br> > > <br> > [</font></tt><a href="http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm"><tt><font size=2>http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.htm</font></tt></a><tt><font size=2><br> > > l] , especially comment 1 (\"Is the WG planning to provide <br> > an ITS Rule <br> > > file along with the specification (e.g. as a non-normative <br> > > appendix)?\") Pleasekeep us in the loop during your <br> > discussion of the <br> > > comments.<br> > > <br> > > <br> > > <br> > <br> <br> <br> </font></tt> <br> --=_alternative 0071744D88257329_=--
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> 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. Best regards, John Boyer > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 10 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > Various > Various comments on XForms 1.1 > > Comment: > The Working Group endorses the coment sent by Yves Savourel > http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0009.html] > , especially comment 1 (\"Is the WG planning to provide an ITS Rule file > along with the specification (e.g. as a non-normative appendix)?\") > Pleasekeep us in the loop during your discussion of the comments. > > >
PROBLEM ID: 38
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, See this post from Norm Walsh: http://norman.walsh.name/2007/04/30/hrri This is something to keep in mind for future editions of the XForms spec once the RFC is out of draft status. Currently, XForms refers to the XLink specification for xforms:load, but it seems not for xforms:submission/(@action|@resource) or in other places. This does not make it very clear whether this section of XLink must be followed: http://www.w3.org/TR/xlink/#link-locators Further, even that section of XLink is obscure to me. So I think that once HHRIs are specified in that RFC, XForms should simply refer to that RFC to specify how any URI specified by a form author should be handled. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Erik, we decided to defer this to future XForms, which may consider supporting HRRIs after IRI support is added. Regards, Ulrich Nicolas Lissé For the Forms WG > All, > > See this post from Norm Walsh: > > http://norman.walsh.name/2007/04/30/hrri > > This is something to keep in mind for future editions of the XForms spec > once the RFC is out of draft status. > > Currently, XForms refers to the XLink specification for xforms:load, but > it seems not for xforms:submission/(@action|@resource) or in other > places. This does not make it very clear whether this section of XLink > must be followed: > > http://www.w3.org/TR/xlink/#link-locators > > Further, even that section of XLink is obscure to me. So I think that > once HHRIs are specified in that RFC, XForms should simply refer to that > RFC to specify how any URI specified by a form author should be handled. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 113
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 2) Section 2 mentions 'HTML forms' and 'HTML Forms'. The capitalization probably needs to be consistent throughout the document. 3) Section 2.1, "It is clear that we are collecting a value tht represents whether cash or credit card is being used..." Probably need to say '...cash or a credit card...' just to be more grammatically correct. 4) Section 2.3, "...because the evaluation context nodes for computed expressions are determined by the bind ref binding expression..." ref should be nodeset here, since @ref isn't valid on a xf:bind.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Thanks for these, Aaron. The spec is changed, but I did not diff-mark them. Best regards, John Boyer > > 2) Section 2 mentions 'HTML forms' and 'HTML Forms'. The capitalization > probably needs to be consistent throughout the document. > 3) Section 2.1, "It is clear that we are collecting a value tht represents > whether cash or credit card is being used..." Probably need to say > '...cash or a credit card...' just to be more grammatically correct. > 4) Section 2.3, "...because the evaluation context nodes for computed > expressions are determined by the bind ref binding expression..." ref > should be nodeset here, since @ref isn't valid on a xf:bind. > >
PROBLEM ID: 35
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Gary F Stevens" <gfsteven@us.ibm.com> This is a list of typos and other small errors I have come across in the XForms 1.1 Working Draft: 3.3.1, version attribute, last sentence before the Note: The word "version" is misspelled "versoin." 3.3.2, resource attribute, first paragraph, last sentence: The sentence "If the host language may treat failure to traverse the link as an exception (4.5.2 The xforms-link-exception Event)" needs to be reworded. 4.6.1, first and second bullets: The use of quotation marks is different between the two bullets. The first one says 'the "incremental="true" setting' while the second one says 'the "incremental=true" setting.' 7.6, last sentence: There is a dash missing between "binding" and "exception". 9.3.1, number attribute, first paragraph, second sentence: The letter "i" in the word "if" at the start of the sentence needs to be capitalized. 10.10.2, second paragraph, first sentence: The word "to" is misspelled "ot" and the word "the" is misspelled "th." 11.2, first paragraph, second sentence: There is a closing parenthesis without an opening parenthesis. 11.2, second bullet, second sentence: The letter "i" in the word "if" at the start of the sentence needs to be capitalized. 11.7.2, first paragraph, first sentence: The sentence is missing the word "have"; it currently reads "The submission element can optionally a child element named verb,..." Gary F Stevens gfsteven@us.ibm.com Software Group - Emerging Standards IBM/US/Raleigh-RTP
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Gary, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > > > > This is a list of typos and other small errors I have come across in the > XForms 1.1 Working Draft: > > > 3.3.1, version attribute, last sentence before the Note: The word > "version" is misspelled "versoin." > > 3.3.2, resource attribute, first paragraph, last sentence: The sentence "If > the host language may treat failure to traverse the link as an exception > (4.5.2 The xforms-link-exception Event)" needs to be reworded. > > 4.6.1, first and second bullets: The use of quotation marks is different > between the two bullets. The first one says 'the "incremental="true" > setting' while the second one says 'the "incremental=true" setting.' > > 7.6, last sentence: There is a dash missing between "binding" and > "exception". > > 9.3.1, number attribute, first paragraph, second sentence: The letter "i" > in the word "if" at the start of the sentence needs to be capitalized. > > 10.10.2, second paragraph, first sentence: The word "to" is misspelled "ot" > and the word "the" is misspelled "th." > > 11.2, first paragraph, second sentence: There is a closing parenthesis > without an opening parenthesis. > 11.2, second bullet, second sentence: The letter "i" in the word "if" at > the start of the sentence needs to be capitalized. > > 11.7.2, first paragraph, first sentence: The sentence is missing the word > "have"; it currently reads "The submission element can optionally a child > element named verb,..." > > Gary F Stevens > gfsteven@us.ibm.com > Software Group - Emerging Standards > IBM/US/Raleigh-RTP > >
PROBLEM ID: 124
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> Move the current abstract text to Section 2 Introduction to XForms, and add appropriate abstract text stating what the document is in the abstract section. Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract text is really an introduction to XForms.
FOLLOWUP 1:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear CDF WG, 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. Regards, Nick Van den Bleeken > Move the current abstract text to Section 2 Introduction to XForms, and add > appropriate abstract text stating what the document is in the abstract > section. > Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract > text is really an introduction to XForms. > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear CDF WG, 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. Regards, Nick Van den Bleeken > Move the current abstract text to Section 2 Introduction to XForms, and add > appropriate abstract text stating what the document is in the abstract > section. > Rationale: http://www.w3.org/2001/06/manual/#Abstract, the current abstract > text is really an introduction to XForms. > >
PROBLEM ID: 94
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
3.3.4 The bind Element
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#structure-bind-element Please add a link to Section 6 for details of MIPS Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Done. Please see the editor's draft available from the Forms WG website. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#structure-bind-element > > Please add a link to Section 6 for details of MIPS > > Steven > >
PROBLEM ID: 86
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
There is an 'accept' with no edits here because we basically agreed not to do some work that had not already been done.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, Let's continue with some schema questions. As discussed in this thread: http://lists.w3.org/Archives/Public/public-forms/2007May/0074.html there is a pending action item to amend the spec so that "revalidate only perform validation of datatypes, not structural validation, *except* during submission". Now I am just wondering how an implementation can do this. If you assign datatypes with xforms:bind or xsi:type, then it is quite easy. Now if you don't have those, but the types come directly from the schema, what do you do? Let's say I define a simple type like this in a schema: <xs:simpleType name="state"> <xs:restriction base="xs:string"> <xs:enumeration value="AL"/> ... I just wouldn't know what nodes in the document have this type. Of course, I know it if I write in my schema: <xs:element name="state" type="dmv:state"/> But this may or may not be a top-level definition in my schema. If it is, then I can assume that any element called "state" will have type state. So I validate the content of the element and there is no problem. What if this is not a top-level definition? Should an implementation do the following: 1. Do a full validation. 2. While doing so, annotate nodes with appropriate type information. 3. Use that type information during revalidate. But then, what happens if you do any of the following: * xforms:insert * submission with instance replacement The newly created nodes won't have any type information associated with them, unless you do a full revalidation. So should we expect that full validation occurs "when needed" to determine node types? Or am I missing something? Feedback would be appreciated on this. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, At the last face-to-face meeting, the working group resolved to nullify the offending action item you mentioned below, so the spec change that would result in the problems you identify below will not be made. We trust that this satisfies your last call comment. Thank you, John Boyer > > All, > > Let's continue with some schema questions. As discussed in this > thread: > > http://lists.w3.org/Archives/Public/public-forms/2007May/0074.html > > there is a pending action item to amend the spec so that "revalidate > only perform validation of datatypes, not structural validation, > *except* during submission". > > Now I am just wondering how an implementation can do this. If you > assign datatypes with xforms:bind or xsi:type, then it is quite > easy. > > Now if you don't have those, but the types come directly from the > schema, what do you do? > > Let's say I define a simple type like this in a schema: > > <xs:simpleType name="state"> > <xs:restriction base="xs:string"> > <xs:enumeration value="AL"/> > ... > > I just wouldn't know what nodes in the document have this type. Of > course, I know it if I write in my schema: > > <xs:element name="state" type="dmv:state"/> > > But this may or may not be a top-level definition in my schema. If it > is, then I can assume that any element called "state" will have type > state. So I validate the content of the element and there is no > problem. > > What if this is not a top-level definition? Should an implementation > do the following: > > 1. Do a full validation. > 2. While doing so, annotate nodes with appropriate type information. > 3. Use that type information during revalidate. > > But then, what happens if you do any of the following: > > * xforms:insert > * submission with instance replacement > > The newly created nodes won't have any type information associated > with them, unless you do a full revalidation. So should we expect that > full validation occurs "when needed" to determine node types? > > Or am I missing something? > > Feedback would be appreciated on this. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 13
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 4 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 3.2.2 Responsibility for useability of IRIs unclear Comment: The host language may permit a Linking Attributes Collection to be applied to XForms elements as an alternate means of obtaining content related to the element. An example is the src attribute from [XHTML 1.0]. The schedule by which link traversal occurs is defined by the host language. If the link traversal fails, the host language may dispatch xforms-link-exception or xforms-link-error to the model associated with the in-scope evaluation context node of the element that bears the Linking Attributes Collection for the failed link. Does this mean that the host language is responsible whether XForms allows for using IRIs [http://www.ietf.org/rfc/rfc3987.txt] or not? Please answer this question in the specification and provide a reference (normative or informative, depending on the answer) to the IRI specification.
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Felix, due to other last call comments, src was moved from host language control to XForms, where it is governed by rules of xsd:anyURI from schema 1.0. Since Schema 1.0 doesn't support IRIs clearly and completely we don't reference the IRI RFC. Regards, Ulrich Nicolas Lissé For the Forms WG > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 4 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 3.2.2 > Responsibility for useability of IRIs unclear > > Comment: > > The host language may permit a Linking Attributes Collection to be > applied to XForms elements as an alternate means of obtaining content > related to the element. An example is the src attribute from [XHTML 1.0]. > The schedule by which link traversal occurs is defined by the host > language. If the link traversal fails, the host language may dispatch > xforms-link-exception or xforms-link-error to the model associated with > the in-scope evaluation context node of the element that bears the Linking > Attributes Collection for the failed link. > > Does this mean that the host language is responsible whether XForms allows > for using > IRIs [http://www.ietf.org/rfc/rfc3987.txt] > or not? Please answer this question in the specification and provide a > reference (normative or informative, depending on the answer) to the IRI > specification. > > > > >
PROBLEM ID: 93
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#structure-model-instance (Sorry that these are so late, but I was rereading the spec in the plane this week, and saw these things, and thought better to comment than not) This section says "If both the resource attribute and inline content are provided, the inline content takes precedence as described at 4.2.1 The xforms-model-construct Event. " Are we sure that this is the best approach? I seem to remember that the discussion was about freeing two birds with one key: If the resource URL fails, then use the inline content. The advantage being, the inline instance can provide a template, and the resource can supply the 'saved' version. So the first time you run an application, you get the default content (such as an empty to-do list), and when you save it to some resource, future times you start up you get the saved version. Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Actually, this is not how the resource attribute works and was not part of the discussion about adding the resource attribute. The resource attribute is not even resolved unless there is no inline content. The intent was to allow something *similar* to what you have described, though. When a form is first served out to the user, their may be no prepopulation data for the instance, in which case it is left blank and thus the resource attribute is resolved and the empty template instance data is used. The user may then interact with the instance data and "save" the instance data. This may occur by submitting the data to a server-side database or, in a document-centric XForms system, it may occur by placing the serialization of the instance data into the xforms:instance before serializing the document containing the XForm to disk. Either way, when the form is next provided to the user, the saved instance data either is or can be placed into the xforms:instance element as prepopulation data that overrides the resource attribute. In conclusion, the resolution of the resource attribute only after checking for inline content is by design, so I hope that this response satisfies your concern about the behavior of the resource attribute. Thanks, John Boyer
PROBLEM ID: 28
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> Once a binding expression on an element is evaluated, XForms uses the identified node as the context node for other attributes on the same element. One example where that creates a limitation is given in the following last call comment: http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html But other cases exist. For example, if an instance has three instance nodes as follows: <data> <a>2</a> <b>2</b> <c>4</c> </data> then one must write the following to put the result of a+b into c: <bind nodeset="c" calculate="../a + ../b"/> The excessive dots are a nuisance, and when the novice writes what is reasonable to expect-- calculate="a+b"-- the result is NaN. This is because the calculate is interpreted relative to the node c, and the node c has no child elements named a and b. The dots are needed to traverse up to the parent of c so that its siblings may be obtained. The problem becomes more acute in larger formulae, which occur often in constraints. It should be noted that fixing this problem might mean that the above bind would no longer be equal to the following nested bind (because the outer bind sets the evaluation context for the inner bind): <bind nodeset="c"> <bind calculate="../a + ../b"/> </bind> It is a decision point as to whether preserving that equivalence between the nested and non-nested bind is important. If not, then the nested bind would give another way to get the old 1.0 behavior back for those who want it. If so, then that might simply affect how the problem is solved. Needless to say, it would be too problematic for the existing XForms community to do away with the current method of determining the evaluation context for attributes like @calculate on bind or @value on setvalue. So we would need some kind of attribute for turning on a different method. This attribute could *default* to the new method when the XForms model @version attribute is set to 1.1. Perhaps something like <model unifiedcontext="false" version="1.1" ...> would suffice to keep the old context evaluation in 1.0, and one could optionally write unifiedcontext="true" to make the change to having all attributes of an element use the same eval context. And, unifiedcontext="true" could be the default for version="1.1" XForms. I don't have a good solution yet for how this could be done if the nested bind and non-nested bind cases above must remain equivalent, but last call rules say my proposal does not have to be complete, and in this case, I call out this equivalence as a decision point, so we don't have to solve it if the answer is no. John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> John, we agree that we need a simpler version, but that it is in scope of XForms 1.2, so this issue is deferred. Regards, Ulrich Nicolas Lissé For the Forms WG > Once a binding expression on an element is evaluated, XForms uses the > identified node as the context node for other attributes on the same > element. > > One example where that creates a limitation is given in the following last > call comment: > http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html > > But other cases exist. For example, if an instance has three instance > nodes as follows: > > <data> > <a>2</a> > <b>2</b> > <c>4</c> > </data> > > then one must write the following to put the result of a+b into c: > > <bind nodeset="c" calculate="../a + ../b"/> > > The excessive dots are a nuisance, and when the novice writes what is > reasonable to expect-- calculate="a+b"-- the result is NaN. This is > because the calculate is interpreted relative to the node c, and the node > c has no child elements named a and b. The dots are needed to traverse up > to the parent of c so that its siblings may be obtained. > > The problem becomes more acute in larger formulae, which occur often in > constraints. > > It should be noted that fixing this problem might mean that the above bind > would no longer be equal to the following nested bind (because the outer > bind sets the evaluation context for the inner bind): > > <bind nodeset="c"> > <bind calculate="../a + ../b"/> > </bind> > > It is a decision point as to whether preserving that equivalence between > the nested and non-nested bind is important. If not, then the nested bind > would give another way to get the old 1.0 behavior back for those who want > it. If so, then that might simply affect how the problem is solved. > > Needless to say, it would be too problematic for the existing XForms > community to do away with the current method of determining the evaluation > context for attributes like @calculate on bind or @value on setvalue. So > we would need some kind of attribute for turning on a different method. > This attribute could *default* to the new method when the XForms model > @version attribute is set to 1.1. > > Perhaps something like <model unifiedcontext="false" version="1.1" ...> > would suffice to keep the old context evaluation in 1.0, and one could > optionally write unifiedcontext="true" to make the change to having all > attributes of an element use the same eval context. And, > unifiedcontext="true" could be the default for version="1.1" XForms. > > I don't have a good solution yet for how this could be done if the nested > bind and non-nested bind cases above must remain equivalent, but last call > rules say my proposal does not have to be complete, and in this case, I > call out this equivalence as a decision point, so we don't have to solve > it if the answer is no. > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 114
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
Editorial fixes, most of which were accepted. Non-accepted are not technical (e.g. the version of XHTML we cite).
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 5) Section 3, Document structure - mentions XHTML 1.0. Shouldn't that be XHTML 2.0? 6) Section 3.2.3 and 3.2.4 - the string 'IDREF' is used in different fonts at different times but it seems to me it is used the same way in both cases. For example, the phrase "or a bind IDREF value that refers to an ID not on a bind element" is used in both sections and in one place 'id' is used, in another 'ID' is used. And in one place IDREF is in a fixed font and in the other it looks like the default font. It gets confusing. 7) Section 3.3.1 "has no predefined behavior event-based behavior." Doesn't make sense having 'behavior' here twice. 8) Section 3.3.1 - "If any non-default model has a versoin..." version is misspelled. 9) Section 3.3.2 - resource attribute - you are introducing a new attribute to the instance element and don't have it in the 1.1 schema? You could also break the xforms out there that currently use @src on the instance element. -> Section 3.2.2 says that the host language can allow @src on xforms elements, for example. So what should happen if @src and @resource are on the element? Who wins? The text in 3.3.2 says that the host language linking attribute 'MAY' win. That doesn't help anyone. How is a form author supposed to code to that? Seems to me like this change needs more thought. 10) Section 3.3.2 - incomplete sentence -> "If the host language may treat failure to traverse the link as an exception" is an incomplete sentence. 11) Section 3.3.2 - "All data relevant to the XPath data model must be preserved during processing and submission, including processing instructions, comment nodes and all whitespace". What about if @indent is specified on xf:submission? Whitespace won't be preserved during submission then. 12) Section 3.3.4 - "Element bind selects a node-set selected from the instance data" seems like poor wording to me. Why not just say, "Element bind selects a node-set from the instance data"? 13) Section 3.3.4 - two periods terminating the sentence right before section 3.4. 14) Section 3.5 - "Another common approach is to allow unregulated content in a few selected places." Should probably be "...in a few select places."
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, Here are responses to several issues you raised in a last call comment on April 30th. Please let us know if you have any further concerns. Thanks, John Boyer 5) Section 3, Document structure - mentions XHTML 1.0. Shouldn't that be XHTML 2.0? It refers to a 'future version' of XHTML, then cites XHTML 1.0, which very well could be XHTML 2 but also pre-XHTML2 modularization profiles. We cite 1.0 because it is a recommendation. 6) Section 3.2.3 and 3.2.4 - the string 'IDREF' is used in different fonts at different times but it seems to me it is used the same way in both cases. For example, the phrase "or a bind IDREF value that refers to an ID not on a bind element" is used in both sections and in one place 'id' is used, in another 'ID' is used. And in one place IDREF is in a fixed font and in the other it looks like the default font. It gets confusing. The last sentence of 3.2.4 was the parallel of the second to last in 3.2.3. In 3.2.3, the correct fixed font and capitalization was used, but not in 3.2.4. Done. Not diff-marked. 7) Section 3.3.1 "has no predefined behavior event-based behavior." Doesn't make sense having 'behavior' here twice. Removed the entire offending phrase as the independent clause of the sentence is sufficient. Diff-marked. 8) Section 3.3.1 - "If any non-default model has a versoin..." version is misspelled. Fixed as part of a larger fix. Diff-marked. 9) Section 3.3.2 - resource attribute - you are introducing a new attribute to the instance element and don't have it in the 1.1 schema? You could also break the xforms out there that currently use @src on the instance element. -> Section 3.2.2 says that the host language can allow @src on xforms elements, for example. So what should happen if @src and @resource are on the element? Who wins? The text in 3.3.2 says that the host language linking attribute 'MAY' win. That doesn't help anyone. How is a form author supposed to code to that? Seems to me like this change needs more thought. XForms now adds the src attribute to the instance element, rather than depending on this attribute from the host language. A note was added to 3.2.2 (linking attributes), the attribute was added to 3.3.2 (instance element), and the description of model construction in 4.2.1 is also modified. Diff-marked. 10) Section 3.3.2 - incomplete sentence -> "If the host language may treat failure to traverse the link as an exception" is an incomplete sentence. The problem is fixed via the substantive change to add src to instance. Removal of the word 'If' is not directly diff-marked. 11) Section 3.3.2 - "All data relevant to the XPath data model must be preserved during processing and submission, including processing instructions, comment nodes and all whitespace". What about if @indent is specified on xf:submission? Whitespace won't be preserved during submission then. Changed to "during process and as input to submission serialization" Diff-marked. 12) Section 3.3.4 - "Element bind selects a node-set selected from the instance data" seems like poor wording to me. Why not just say, "Element bind selects a node-set from the instance data"? Done. Not diff-marked. 13) Section 3.3.4 - two periods terminating the sentence right before section 3.4. Done. Not diff-marked. 14) Section 3.5 - "Another common approach is to allow unregulated content in a few selected places." Should probably be "...in a few select places." Done. Not diff-marked.
PROBLEM ID: 112
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it was better defined. But it is still there.
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for the comment. This hsa now been fixed. Best wishes, Steven Pemberton For the FOrms WG > 1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it > was better defined. But it is still there.
PROBLEM ID: 56
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#structure-attrs-common Please allow both id= and xml:id=
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group agreed that it should be clarified that xml:id can also be used, not just the id attribute that is listed in the common attributes. At the most recent face to face meeting, a Note was added to point this out. Please see the revised text in the editor's draft available from the working group website and let us know if you have any further concerns about this issue. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#structure-attrs-common > > Please allow both id= and xml:id= > > >
PROBLEM ID: 8
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: Agree
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 5 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 4.2.1 IRIs for external schema locations possible? Comment: As part of the xforms-model-construct Event, you describe that all XML Schemas are loaded. Is it possible to use IRIs [http://www.ietf.org/rfc/rfc3987.txt] for identifying external schemas? See also comment 4 of the i18n core comments.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Of the four points you make below, three are editorial and have been corrected. In addition, the use of the "barename" terminology was incorrect and has also been fixed. It was alluding to a barename XPointer, but the terminology has now been corrected to indicate a fragment identifier URI Reference (including the leading # mark), which is the proper term from RFC 2396. Please see the diff-marked text in the editor's draft available from the Forms WG website and let us know if you have any more concerns about this issue. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#structure-model-instance > > Has the sentence "If the host language may treat failure to traverse > the link as an exception (4.5.2 The xforms-link-exception Event)." > > It also contains the sentence ending: > > "with a resource-uri indicating either the URI for an external > instance, a barename URI reference to an identified internal instance, > or empty string for an with an unidentified internal instance. .|" > which > - ends with two full-stops > - "empty string for an with an" > - I don't know what a barename URI reference is. > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Felix, XForms 1.1 is based on XML Schema 1.0 second ed., which does not appear to support all IRIs in the xsd:anyURI type. Therefore we will defer the support of all IRIs to a future version of XForms, which may be based on a version of schema later than 1.0 that will support all IRIs. Regards, Nick Van den Bleeken > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 5 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 4.2.1 > IRIs for external schema locations possible? > > Comment: > As part of the xforms-model-construct Event, you describe that all XML > Schemas are loaded. Is it possible to use > IRIs [http://www.ietf.org/rfc/rfc3987.txt] > for identifying external schemas? See also comment 4 of the i18n core > comments. > > >
REPLY 3:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> John, we agree that we need a simpler version, but that it is in scope of XForms 1.2, so this issue is deferred. Regards, Ulrich Nicolas Lissé For the Forms WG > Once a binding expression on an element is evaluated, XForms uses the > identified node as the context node for other attributes on the same > element. > > One example where that creates a limitation is given in the following last > call comment: > http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0042.html > > But other cases exist. For example, if an instance has three instance > nodes as follows: > > <data> > <a>2</a> > <b>2</b> > <c>4</c> > </data> > > then one must write the following to put the result of a+b into c: > > <bind nodeset="c" calculate="../a + ../b"/> > > The excessive dots are a nuisance, and when the novice writes what is > reasonable to expect-- calculate="a+b"-- the result is NaN. This is > because the calculate is interpreted relative to the node c, and the node > c has no child elements named a and b. The dots are needed to traverse up > to the parent of c so that its siblings may be obtained. > > The problem becomes more acute in larger formulae, which occur often in > constraints. > > It should be noted that fixing this problem might mean that the above bind > would no longer be equal to the following nested bind (because the outer > bind sets the evaluation context for the inner bind): > > <bind nodeset="c"> > <bind calculate="../a + ../b"/> > </bind> > > It is a decision point as to whether preserving that equivalence between > the nested and non-nested bind is important. If not, then the nested bind > would give another way to get the old 1.0 behavior back for those who want > it. If so, then that might simply affect how the problem is solved. > > Needless to say, it would be too problematic for the existing XForms > community to do away with the current method of determining the evaluation > context for attributes like @calculate on bind or @value on setvalue. So > we would need some kind of attribute for turning on a different method. > This attribute could *default* to the new method when the XForms model > @version attribute is set to 1.1. > > Perhaps something like <model unifiedcontext="false" version="1.1" ...> > would suffice to keep the old context evaluation in 1.0, and one could > optionally write unifiedcontext="true" to make the change to having all > attributes of an element use the same eval context. And, > unifiedcontext="true" could be the default for version="1.1" XForms. > > I don't have a good solution yet for how this could be done if the nested > bind and non-nested bind cases above must remain equivalent, but last call > rules say my proposal does not have to be complete, and in this case, I > call out this equivalence as a decision point, so we don't have to solve > it if the answer is no. > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 58
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#structure-model-instance Has the sentence "If the host language may treat failure to traverse the link as an exception (4.5.2 The xforms-link-exception Event)." It also contains the sentence ending: "with a resource-uri indicating either the URI for an external instance, a barename URI reference to an identified internal instance, or empty string for an with an unidentified internal instance. .|" which - ends with two full-stops - "empty string for an with an" - I don't know what a barename URI reference is.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Of the four points you make below, three are editorial and have been corrected. In addition, the use of the "barename" terminology was incorrect and has also been fixed. It was alluding to a barename XPointer, but the terminology has now been corrected to indicate a fragment identifier URI Reference (including the leading # mark), which is the proper term from RFC 2396. Please see the diff-marked text in the editor's draft available from the Forms WG website and let us know if you have any more concerns about this issue. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#structure-model-instance > > Has the sentence "If the host language may treat failure to traverse > the link as an exception (4.5.2 The xforms-link-exception Event)." > > It also contains the sentence ending: > > "with a resource-uri indicating either the URI for an external > instance, a barename URI reference to an identified internal instance, > or empty string for an with an unidentified internal instance. .|" > which > - ends with two full-stops > - "empty string for an with an" > - I don't know what a barename URI reference is. > >
PROBLEM ID: 55
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#structure-attrs-common http://www.w3.org/TR/xforms11/#structure-attrs-link It really looks like @src has been removed, and replaced by @resource. I think this sends the wrong message, especially if the reasoning is that the host language should provide src, since @id was not included in XForms 1.0 for that reason, and now has been added to XForms 1.1. Please add @src back, lest implementors should leave it out, and old forms not work. (@resource will be dealt with in another issue).
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group agreed with you that it was better to specify src on instance as part of XForms rather than relying upon the host language to add it. This was viewed as being consistent with our earlier addition of the id attribute to the common attributes (i.e. we agreed it was generally true that if an attribute is needed to produce some core required behavior, then the attribute should appear in the XForms schema). You can find the revised text with diff marks in the editor's draft available from the Forms WG website at http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance Please let us know if you have any concerns about this resolution. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#structure-attrs-common > http://www.w3.org/TR/xforms11/#structure-attrs-link > > It really looks like @src has been removed, and replaced by > @resource. I think this sends the wrong message, especially if the > reasoning is that the host language should provide src, since @id was > not included in XForms 1.0 for that reason, and now has been added to > XForms 1.1. Please add @src back, lest implementors should leave it > out, and old forms not work. (@resource will be dealt with in another > issue). > >
PROBLEM ID: 2
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> I have a question regarding the validity of the XForm's testsuite case 3.4.1[1] with respect to mustUnderstand [2]. I know that some of these issues have already been raised [3] but wanted to state that Mozilla XForms is currently not adding support for this [4] due to some of these issues. We are considering the test case 3.4.1 to be invalid until these issues are resolved. Here are some of the issues with mustUnderstand: - When does it get evaluated? Must it be handled prior to xforms-ready or say if it's in a switch/case, only when the case is activated? - Can mustUnderstand be manipulated by script? If nodes are dynamically added to layout but conflicts with mustUnderstand, what error should occur? Perhaps a better fallback mechanism should be used. Though I might propose completely removing mustUnderstand as I don't know of anyone who has implemented it. Another thought is to seek feedback or give requirements to the CDF WG [5], as they are currently dealing with such issues around mixing namespace documents and content negotiation and fallback handling of unknown content. Regards, Steve Speicher [1] http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3.4/3.4.1/3.4.1.a.xhtml [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255 [5] http://www.w3.org/2004/CDF/
FOLLOWUP 1:
From: Steve K Speicher <sspeiche@us.ibm.com> Steven and Forms WG, I confirm that I am satisfied with this response. Thanks, Steve Speicher Steven Pemberton <xforms-issues@mn.aptest.com> wrote on 06/13/2007 04:32:20 PM: > Steve, > > Thanks for these questions. The WG has resolved to remove > 'mustunderstand' from > the spec. > > Although your mail doesn't actually suggest a position, would you please reply > to this email to confirm that you are satisified with this response? > > Many thanks, > > For the Forms WG, > > Steven Pemberton > > > I have a question regarding the validity of the XForm's testsuite case > > 3.4.1[1] with respect to mustUnderstand [2]. > > > > I know that some of these issues have already been raised [3] but wanted > > to state that Mozilla XForms is currently not adding support for this [4] > > due to some of these issues. > > > > We are considering the test case 3.4.1 to be invalid until these issues > > are resolved. > > > > Here are some of the issues with mustUnderstand: > > - When does it get evaluated? Must it be handled prior to xforms-ready > > or say if it's in a switch/case, only when the case is activated? > > - Can mustUnderstand be manipulated by script? If nodes are dynamically > > added to layout but conflicts with mustUnderstand, what error should > > occur? > > > > Perhaps a better fallback mechanism should be used. Though I might > > propose completely removing mustUnderstand as I don't know of anyone who > > has implemented it. Another thought is to seek feedback or give > > requirements to the CDF WG [5], as they are currently dealing with such > > issues around mixing namespace documents and content negotiation and > > fallback handling of unknown content. > > > > Regards, > > Steve Speicher > > > > [1] > > http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3. > 4/3.4.1/3.4.1.a.xhtml > > [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand > > [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149 > > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255 > > [5] http://www.w3.org/2004/CDF/ > > > > > >
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Steve, Thanks for these questions. The WG has resolved to remove 'mustunderstand' from the spec. Although your mail doesn't actually suggest a position, would you please reply to this email to confirm that you are satisified with this response? Many thanks, For the Forms WG, Steven Pemberton > I have a question regarding the validity of the XForm's testsuite case > 3.4.1[1] with respect to mustUnderstand [2]. > > I know that some of these issues have already been raised [3] but wanted > to state that Mozilla XForms is currently not adding support for this [4] > due to some of these issues. > > We are considering the test case 3.4.1 to be invalid until these issues > are resolved. > > Here are some of the issues with mustUnderstand: > - When does it get evaluated? Must it be handled prior to xforms-ready > or say if it's in a switch/case, only when the case is activated? > - Can mustUnderstand be manipulated by script? If nodes are dynamically > added to layout but conflicts with mustUnderstand, what error should > occur? > > Perhaps a better fallback mechanism should be used. Though I might > propose completely removing mustUnderstand as I don't know of anyone who > has implemented it. Another thought is to seek feedback or give > requirements to the CDF WG [5], as they are currently dealing with such > issues around mixing namespace documents and content negotiation and > fallback handling of unknown content. > > Regards, > Steve Speicher > > [1] > http://www.w3.org/MarkUp/Forms/Test/XForms1.0/Edition2/Chapt3/3.4/3.4.1/3.4.1.a.xhtml > [2] http://www.w3.org/TR/xforms/slice3.html#module-mustUnderstand > [3] http://lists.w3.org/Archives/Public/www-forms/2002Aug/0149 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=299255 > [5] http://www.w3.org/2004/CDF/ > > >
REPLY 2:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for the comment. This hsa now been fixed. Best wishes, Steven Pemberton For the FOrms WG > 1) I thought that the 1.1 spec would drop/deprecate MustUnderstand until it > was better defined. But it is still there.
PROBLEM ID: 87
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, XForms 1.1 mentions in 4.3.5: "the node satisfies all applicable XML schema definitions (including those associated by [...] an external or an inline schema [...]) I would like a precision on what "applicable" means for schema types when types are not assigned with xforms:bind or xsi:type. If I do a correct job below, then you will see that things are currently not clear. Assume a schema defining types in the: xmlns:foo="http://example.org/schema/foo" namespace (that schema does not import other schemas). I import the schema into a model with three instances: <xforms:model schema="foo.xsd"> <xforms:instance id="instance-1"> <foo:form> ... </foo:form> </xforms:instance> <xforms:instance id="instance-2"> <bar:form> ... </bar:form> </xforms:instance> <xforms:instance id="instance-3"> <foo:undefined> ... </foo:undefined> </xforms:instance> </xforms:model> Assume foo.xsd defines only a complex type for foo:form, but no type for foo:undefined, and no type for bar:form (bar maps to a different namespace, and there is no schema for "bar"). It seems to me that foo:form for sure has an "applicable" schema definition. So no problem here. Now what's the algorithm for bar:form? It certainly doesn't have any schema definition: there is no schema for namespace "bar". So I guess this means there is no "applicable" definition for bar:form. However, you could decide to recurse the tree and validate further, or not. Now what about foo:undefined? There is a schema for namespace "foo", but none for the type foo:undefined. Does this mean there there is an applicable definition or not? Same thing, you could decide to recurse the tree and validate further, or not. Now I shouldn't even have to discuss this in these terms, because XML schema provides options already, see "3.10.1 The Wildcard Schema Component" in [1]. There are three ways you can process a subtree in schema: *strict* There must be a top-level declaration for the item available, or the item must have an xsi:type, and the item must be ·valid· as appropriate. *skip* No constraints at all: the item must simply be well-formed XML. *lax* If the item has a uniquely determined declaration available, it must be ·valid· with respect to that definition, that is, ·validate· if you can, don't worry if you can't. So it seems to me that here the question is whether we process instances with "strict" or "lax" processing (and possibly "skip" as well). XSLT 2.0 solves the problem by providing a "validation" attribute [2] which can have value "strict", "lax", and two others ("preserve" and "strip") which are probably not relevant here. XSLT 2.0 also provides a "type" attribute, exclusive with "validation". In XForms, we have a similar situation: we can explicitly bind a type to the root element of an instance with xforms:bind or with xsi:type. If we do, everything is fine. If we don't, THEN we want to specify whether we want strict or lax validation. It seems to me then, if my understanding is correct, that there is an omission in XForms at this point regarding how validation is performed. We should: 1. Explicitly specify whether instance validation is performed in "strict" or "lax" mode when no type is assigned to the root element of the instance. 2. Ideally, provide an option to specify whether "strict", "lax" or even "skip" mode is applied. This could be done with a simple attribute on xforms:instance: <xforms:instance validation="lax"> 3. Possibly, also provide the option for "skip" mode, to specifically exclude an instance from validation. Comments on this are of course welcome. -Erik [1] http://www.w3.org/TR/xmlschema-1/ [2] http://www.w3.org/TR/xslt20/#validation -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, Based on your further explanations as well as explanations from Michael Sperberg-McQueen, the working group resolved to adopt the default of lax schema processing for initializing the schema validation episode. Furthermore, the applicability of schema definitions is based on this definition with the *requirement* to recursively descend when a schema declaration is not found for an element. This mirrors the wording in XSLT 2.0. The editor's draft now reflects this information in the model element definition, and an informative note was added to the revalidate event to point to the definition. Best regards, John Boyer > > All, > > XForms 1.1 mentions in 4.3.5: > > "the node satisfies all applicable XML schema definitions > (including those associated by [...] an external or an inline > schema [...]) > > I would like a precision on what "applicable" means for schema types > when types are not assigned with xforms:bind or xsi:type. If I do a > correct job below, then you will see that things are currently not > clear. > > Assume a schema defining types in the: > > xmlns:foo="http://example.org/schema/foo" > > namespace (that schema does not import other schemas). I import the > schema into a model with three instances: > > <xforms:model schema="foo.xsd"> > > <xforms:instance id="instance-1"> > <foo:form> > ... > </foo:form> > </xforms:instance> > > <xforms:instance id="instance-2"> > <bar:form> > ... > </bar:form> > </xforms:instance> > > <xforms:instance id="instance-3"> > <foo:undefined> > ... > </foo:undefined> > </xforms:instance> > > </xforms:model> > > Assume foo.xsd defines only a complex type for foo:form, but no type > for foo:undefined, and no type for bar:form (bar maps to a different > namespace, and there is no schema for "bar"). > > It seems to me that foo:form for sure has an "applicable" schema > definition. So no problem here. > > Now what's the algorithm for bar:form? It certainly doesn't have any > schema definition: there is no schema for namespace "bar". So I guess > this means there is no "applicable" definition for bar:form. However, > you could decide to recurse the tree and validate further, or not. > > Now what about foo:undefined? There is a schema for namespace "foo", > but none for the type foo:undefined. Does this mean there there is an > applicable definition or not? Same thing, you could decide to recurse > the tree and validate further, or not. > > Now I shouldn't even have to discuss this in these terms, because XML > schema provides options already, see "3.10.1 The Wildcard Schema > Component" in [1]. > > There are three ways you can process a subtree in schema: > > *strict* > > There must be a top-level declaration for the item available, or > the item must have an xsi:type, and the item must be ?valid? as > appropriate. > > *skip* > > No constraints at all: the item must simply be well-formed XML. > > *lax* > > If the item has a uniquely determined declaration available, it > must be ?valid? with respect to that definition, that is, > ?validate? if you can, don't worry if you can't. > > So it seems to me that here the question is whether we process > instances with "strict" or "lax" processing (and possibly "skip" as > well). > > XSLT 2.0 solves the problem by providing a "validation" attribute [2] > which can have value "strict", "lax", and two others ("preserve" and > "strip") which are probably not relevant here. > > XSLT 2.0 also provides a "type" attribute, exclusive with > "validation". In XForms, we have a similar situation: we can > explicitly bind a type to the root element of an instance with > xforms:bind or with xsi:type. If we do, everything is fine. If we > don't, THEN we want to specify whether we want strict or lax > validation. > > It seems to me then, if my understanding is correct, that there is an > omission in XForms at this point regarding how validation is > performed. We should: > > 1. Explicitly specify whether instance validation is performed in > "strict" or "lax" mode when no type is assigned to the root element > of the instance. > > 2. Ideally, provide an option to specify whether "strict", "lax" or > even "skip" mode is applied. This could be done with a simple > attribute on xforms:instance: > > <xforms:instance validation="lax"> > > 3. Possibly, also provide the option for "skip" mode, to specifically > exclude an instance from validation. > > Comments on this are of course welcome. > > -Erik > > [1] http://www.w3.org/TR/xmlschema-1/ > [2] http://www.w3.org/TR/xslt20/#validation > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, The working group accepts that we must specify how schemas are applied to instance data based on the namespace involved and the available schema declarations for that namespace. The goal will be to document what current practice is achieving in effect, rather than a specific means of implementing it and rather than adding another feature at this time to provide the form author with control over the process. We intend, with your help of course, to increase both form author control and overall flexibility of schema processing in a future release of XForms. Thank you, John Boyer > > All, > > XForms 1.1 mentions in 4.3.5: > > "the node satisfies all applicable XML schema definitions > (including those associated by [...] an external or an inline > schema [...]) > > I would like a precision on what "applicable" means for schema types > when types are not assigned with xforms:bind or xsi:type. If I do a > correct job below, then you will see that things are currently not > clear. > > Assume a schema defining types in the: > > xmlns:foo="http://example.org/schema/foo" > > namespace (that schema does not import other schemas). I import the > schema into a model with three instances: > > <xforms:model schema="foo.xsd"> > > <xforms:instance id="instance-1"> > <foo:form> > ... > </foo:form> > </xforms:instance> > > <xforms:instance id="instance-2"> > <bar:form> > ... > </bar:form> > </xforms:instance> > > <xforms:instance id="instance-3"> > <foo:undefined> > ... > </foo:undefined> > </xforms:instance> > > </xforms:model> > > Assume foo.xsd defines only a complex type for foo:form, but no type > for foo:undefined, and no type for bar:form (bar maps to a different > namespace, and there is no schema for "bar"). > > It seems to me that foo:form for sure has an "applicable" schema > definition. So no problem here. > > Now what's the algorithm for bar:form? It certainly doesn't have any > schema definition: there is no schema for namespace "bar". So I guess > this means there is no "applicable" definition for bar:form. However, > you could decide to recurse the tree and validate further, or not. > > Now what about foo:undefined? There is a schema for namespace "foo", > but none for the type foo:undefined. Does this mean there there is an > applicable definition or not? Same thing, you could decide to recurse > the tree and validate further, or not. > > Now I shouldn't even have to discuss this in these terms, because XML > schema provides options already, see "3.10.1 The Wildcard Schema > Component" in [1]. > > There are three ways you can process a subtree in schema: > > *strict* > > There must be a top-level declaration for the item available, or > the item must have an xsi:type, and the item must be ?valid? as > appropriate. > > *skip* > > No constraints at all: the item must simply be well-formed XML. > > *lax* > > If the item has a uniquely determined declaration available, it > must be ?valid? with respect to that definition, that is, > ?validate? if you can, don't worry if you can't. > > So it seems to me that here the question is whether we process > instances with "strict" or "lax" processing (and possibly "skip" as > well). > > XSLT 2.0 solves the problem by providing a "validation" attribute [2] > which can have value "strict", "lax", and two others ("preserve" and > "strip") which are probably not relevant here. > > XSLT 2.0 also provides a "type" attribute, exclusive with > "validation". In XForms, we have a similar situation: we can > explicitly bind a type to the root element of an instance with > xforms:bind or with xsi:type. If we do, everything is fine. If we > don't, THEN we want to specify whether we want strict or lax > validation. > > It seems to me then, if my understanding is correct, that there is an > omission in XForms at this point regarding how validation is > performed. We should: > > 1. Explicitly specify whether instance validation is performed in > "strict" or "lax" mode when no type is assigned to the root element > of the instance. > > 2. Ideally, provide an option to specify whether "strict", "lax" or > even "skip" mode is applied. This could be done with a simple > attribute on xforms:instance: > > <xforms:instance validation="lax"> > > 3. Possibly, also provide the option for "skip" mode, to specifically > exclude an instance from validation. > > Comments on this are of course welcome. > > -Erik > > [1] http://www.w3.org/TR/xmlschema-1/ > [2] http://www.w3.org/TR/xslt20/#validation > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 129
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> CDF07 - mustUnderstand module not defined well enough, recommend removing. Delete Rationale: The CDF WG feels that this module should be removed. Here are some of the issues with mustUnderstand: - When does it get evaluated? Must it be handled prior to xforms-ready or say if it's in a switch/case, only when the case is activated? - Can mustUnderstand be manipulated by script? If nodes are dynamically added to layout but conflicts with mustUnderstand, what error should occur? Perhaps a better fallback mechanism should be used. We.d recommend to seek feedback or give requirements to the CDF WG, as we are currently dealing with such issues around mixing namespace documents, content identification, content negotiation and fallback handling of unknown content.
FOLLOWUP 1:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Thank you for the comment. The XForms WG has resolved to remove the mustunderstand model as you suggest. Best wishes, Steven Pemberton For the Forms WG > CDF07 - mustUnderstand module not defined well enough, recommend removing. > Delete > Rationale: The CDF WG feels that this module should be removed. > Here are some of the issues with mustUnderstand: > - When does it get evaluated? Must it be handled prior to xforms-ready > or say if it's in a switch/case, only when the case is activated? > - Can mustUnderstand be manipulated by script? If nodes are dynamically > added to layout but conflicts with mustUnderstand, what error should occur? > Perhaps a better fallback mechanism should be used. We.d recommend to seek > feedback or give requirements to the CDF WG, as we are currently dealing > with such issues around mixing namespace documents, content identification, > content negotiation and fallback handling of unknown content. > >
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thank you for the comment. The XForms WG has resolved to remove the mustunderstand model as you suggest. Best wishes, Steven Pemberton For the Forms WG > CDF07 - mustUnderstand module not defined well enough, recommend removing. > Delete > Rationale: The CDF WG feels that this module should be removed. > Here are some of the issues with mustUnderstand: > - When does it get evaluated? Must it be handled prior to xforms-ready > or say if it's in a switch/case, only when the case is activated? > - Can mustUnderstand be manipulated by script? If nodes are dynamically > added to layout but conflicts with mustUnderstand, what error should occur? > Perhaps a better fallback mechanism should be used. We.d recommend to seek > feedback or give requirements to the CDF WG, as we are currently dealing > with such issues around mixing namespace documents, content identification, > content negotiation and fallback handling of unknown content. > >
PROBLEM ID: 154
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: aaronr@us.ibm.com Full_Name: Aaron Reed Submission from: (NULL) (32.97.110.142) Submitted by: boyerj Date: Mon, 30 Apr 2007 23:56:50 +0200 To: www-forms-editor@w3.org Subject: Section 9 From: "Aaron Reed" <aaronr@us.ibm.com> 15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if there is a host-language defined linking attribute.
FOLLOWUP 1:
From: John Boyer <xforms-issues@aptest.com> Hi Aaron, The working group agreed with you that it was better to specify src on instance as part of XForms rather than relying upon the host language to add it. This was viewed as being consistent with our earlier addition of the id attribute to the common attributes (i.e. we agreed it was generally true that if an attribute is needed to produce some core required behavior, then the attribute should appear in the XForms schema). You can find the revised text with diff marks in the editor's draft available from the Forms WG website at http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance Please let us know if you have any concerns about this resolution. Thanks, John Boyer > Date: Mon, 30 Apr 2007 23:56:50 +0200 > To: www-forms-editor@w3.org > Subject: src attribute on instance > From: "Aaron Reed" <aaronr@us.ibm.com> > > 15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if > there is a host-language defined linking attribute. > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, The working group agreed with you that it was better to specify src on instance as part of XForms rather than relying upon the host language to add it. This was viewed as being consistent with our earlier addition of the id attribute to the common attributes (i.e. we agreed it was generally true that if an attribute is needed to produce some core required behavior, then the attribute should appear in the XForms schema). You can find the revised text with diff marks in the editor's draft available from the Forms WG website at http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#structure-model-instance Please let us know if you have any concerns about this resolution. Thanks, John Boyer > Date: Mon, 30 Apr 2007 23:56:50 +0200 > To: www-forms-editor@w3.org > Subject: src attribute on instance > From: "Aaron Reed" <aaronr@us.ibm.com> > > 15) Section 4.2.1 - item #2 - it mentions @resource but not what happens if > there is a host-language defined linking attribute. > >
PROBLEM ID: 104
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Mark Birbeck" <mark.birbeck@x-port.net> Hello, I'd like to suggest that we have a version attribute that can be used on any element in a host language. This would therefore be a global attribute in the XForms namespace, and might be used as follows: <html xf:version="1.1"> ... </html> My feeling is that this attribute is less about enforcing behaviour of processors, and more about providing a clear indication to authors which type of document they are dealing with. For example, if a form contains a submission that uses the new xf:resource attribute or element, it may not be immediately obvious to a new author as they start to learn XForms, that this is not supported in all processors. Rather than having a flurry of emails on one or other list saying that some example doesn't work, I think we should encourage authors to indicate what standard is being used by a form. Regards, Mark -- Mark Birbeck, formsPlayer mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
FOLLOWUP 1:
From: "Klotz, Leigh" <Leigh.Klotz@xerox.com> There's a typo here; The "a again" should simply be removed. I mistyped this in the text sent to Ulrich. Leigh. -----Original Message----- From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf Of Ulrich Nicolas Lissé Sent: Thursday, June 14, 2007 1:11 PM To: mark.birbeck@x-port.net Cc: www-forms@w3.org; www-forms-editor@w3.org Subject: Re: XForms document versioning (PR#104) Mark, we changed section 3.3.1 to default model version to empty, and defined empty to mean that the processor gets to choose the version. If no version chosen is available, the xforms-version-exception is dispatched to the default model. The declaration on the default model is used to make the choice. Later models may offer declarations of model version but xforms-version-exception is a gain dispatched to the default model if their declarations are incompatible with the version chosen. Regards, Ulrich Nicolas Lissé. For the Forms WG > Hello, > > I'd like to suggest that we have a version attribute that can be used > on any element in a host language. This would therefore be a global > attribute in the XForms namespace, and might be used as follows: > > <html xf:version="1.1"> > ... > </html> > > My feeling is that this attribute is less about enforcing behaviour of > processors, and more about providing a clear indication to authors > which type of document they are dealing with. > > For example, if a form contains a submission that uses the new > xf:resource attribute or element, it may not be immediately obvious to > a new author as they start to learn XForms, that this is not supported > in all processors. Rather than having a flurry of emails on one or > other list saying that some example doesn't work, I think we should > encourage authors to indicate what standard is being used by a form. > > Regards, > > Mark > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > >
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Mark, we changed section 3.3.1 to default model version to empty, and defined empty to mean that the processor gets to choose the version. If no version chosen is available, the xforms-version-exception is dispatched to the default model. The declaration on the default model is used to make the choice. Later models may offer declarations of model version but xforms-version-exception is a gain dispatched to the default model if their declarations are incompatible with the version chosen. Regards, Ulrich Nicolas Lissé. For the Forms WG > Hello, > > I'd like to suggest that we have a version attribute that can be used > on any element in a host language. This would therefore be a global > attribute in the XForms namespace, and might be used as follows: > > <html xf:version="1.1"> > ... > </html> > > My feeling is that this attribute is less about enforcing behaviour of > processors, and more about providing a clear indication to authors > which type of document they are dealing with. > > For example, if a form contains a submission that uses the new > xf:resource attribute or element, it may not be immediately obvious to > a new author as they start to learn XForms, that this is not supported > in all processors. Rather than having a flurry of emails on one or > other list saying that some example doesn't work, I think we should > encourage authors to indicate what standard is being used by a form. > > Regards, > > Mark > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > >
PROBLEM ID: 85
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, XForms mentions in a few places support for xsi:type, in "4.3.5 The xforms-revalidate Event", "6.2.1 Atomic Datatype", and "7.11.4 The id() Function". It is not clear to me if an implementation must support xsi:type attributes on elements when there is no xforms:model/@schema defined, or no inline schema. It is my understanding that the "type" model item property does support XML Schema and XForms built-in data types even in the absence of a schema. But is this true as well of xsi:type attributes? -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, Yes, it is true that xsi:type attributes are supported even when there are no form-declared schema in the form. This is because the validation test in Section 4.3.4 states that validity is based on *all applicable schema definitions* including those coming from xsi:type. Due to the XML Schema recommendation, an existing xsi:type declaration is, by default, applicable to element validity. In general, we follow all rules of XML schema except those that are explicitly mentioned as not being supported. Section 6.2 provides the only mention of schema rules we do not follow (and are allowed not to follow). In that section, we say that schema rules are not applicable if they come from a schema indicated by xsi:schemaLocation or xsi:noNamespaceSchemaLocation. In today's WG telecon, you indicated it would be satisfactory to have a note in the spec to clarify that xsi:type is applicable even if there are no declared schemas, and that note appears in Section 4.3.4 of the editor's draft of the spec available from the WG home page. Thank you, John Boyer > > All, > > XForms mentions in a few places support for xsi:type, in "4.3.5 The > xforms-revalidate Event", "6.2.1 Atomic Datatype", and "7.11.4 The id() > Function". > > It is not clear to me if an implementation must support xsi:type > attributes on elements when there is no xforms:model/@schema defined, or > no inline schema. > > It is my understanding that the "type" model item property does support > XML Schema and XForms built-in data types even in the absence of a > schema. But is this true as well of xsi:type attributes? > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 127
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Kevin E Kelly" <Kevin.Kelly@us.ibm.com> Change "Note that the presence of foreign namespaced elements is subject to the definition of the containing document profile. " To "Note that the presence of foreign namespaced elements is subject to the definition of the containing or compound document profile. " Rationale: Provides clarification for compound document profiles.
FOLLOWUP 1:
From: member-cdf-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Kevin, Thank you for this feedback. The working group has agreed to this change, and the specification will be amended as requested in the last call comment (copied below). An editor's draft of changes is available from the Forms WG homepage, and a version containing this change will be available by tomorrow. Thanks, John Boyer > Change > "Note that the presence of foreign namespaced elements is subject to the > definition of the containing document profile. " > To > "Note that the presence of foreign namespaced elements is subject to the > definition of the containing or compound document profile. " > Rationale: Provides clarification for compound document profiles. > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Kevin, Thank you for this feedback. The working group has agreed to this change, and the specification will be amended as requested in the last call comment (copied below). An editor's draft of changes is available from the Forms WG homepage, and a version containing this change will be available by tomorrow. Thanks, John Boyer > Change > "Note that the presence of foreign namespaced elements is subject to the > definition of the containing document profile. " > To > "Note that the presence of foreign namespaced elements is subject to the > definition of the containing or compound document profile. " > Rationale: Provides clarification for compound document profiles. > >
PROBLEM ID: 91
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: =?iso-8859-1?Q?Ulrich_Nicolas_Liss=E9?= <unl@dreamlab.net> Hello John, great work. Alas, some typos and other minor issues popped up during fine reading. Maybe some of these are contained in XForms 1.0 editions too, but I didn't check this. "3.3 The XForms Core Module" The table contains a wrong attribute definition for the submission element. It says: "... method ("post"|"get"|"put"|delete|"form-data-post"|"urlencoded-post"|QNameButNotNCNAME) ...." The word delete should have double quotes, since it is a fixed value instead of a type. "3.3.1 The model Element" The sentence "This element is not an XForms Action, and has no predefined behavior event-based behavior." has too many behaviors ;-) Remove "behavior" after "predefined". "3.3.2 The instance Element" In the description of the resource attribute there is the sentence "If the host language may treat failure to traverse the link as an exception (4.5.2 The xforms-link-exception Event).", which is not really understandable. Remove "If". "4.5.5 The xforms-version-exception Event" For this event's context information a property "errorinformation" is defined. Shouldn't this be named "error-information" instead to be consistent with the naming scheme of other event's properties (like "resource-uri" or "error-message")? "4.6.1 For input, secret, textarea, range, or upload Controls" The first bullet says "... has the "incremental="true" setting ...", the second "... does not have the "incremental=true" setting". The double quotes for the incremental attribute have to be fixed, and it should be set in <code>-markup. "4.6.3 For select or select1 Controls" Same as above. "7.6 The XForms Function Library" Replace "xforms-binding exception" with "xforms-binding-exception" in the last sentence. "7.8.5 The index() Function" The second sentence "if the specified argument ..." should start uppercase. "7.9.4 The digest() Function" All three expamples for this extension function still show "hash-encode". Replace with "digest". "8.1.5 The output Element" There are two Description paragraphs provided here. They are similar but not identical. The second one seems more accurate, so please delete the first one. "8.3.1 The filename Element" In the description of a then following example "mail/attachment@filename" and "mail/attachment@mediatype" refer to attribute nodes. The correct XPath syntax "mail/attachment/@filename" and "mail/attachment/@mediatype" should be used. "9.3.1 The repeat Element" In the paragraph after the special attributes description the second sentence "if an element of the collection ..." should start uppercase. "9.3.5 The insert Action" The 5th example ("Inserting into a repeat, whether or not it is empty") refers to "repeat R". In the code snippet there is a call to index() function in <xf:insert ... at="index('R')"/> as well as a <xf:setfocus control="R"/>. However, the repeat is missing id="R" which might confuse readers. Maybe it could even be renamed to something more self-explanatory, e.g. "PurchaseOrderRepeat". "9.3.7 The setindex Element" In the paragraph after the special attributes description the third sentence "if the index evaluates to NaN ..." should start uppercase. "9.3.8 Repeat Processing" In list item 2. the second sentence "if the initial startindex ..." should start uppercase. "10.10.2 Processing of the load Action" In the second paragraph "... link between th load element and the remote resource" replace "th " with "the ". "10.15 Iteration of XForms Actions" I don't speak English natively, but the sentence "Counter and Accumlator Variables are Created in Instance Data to Sum a Selection of Values Chosen by the User" hurts my eyes. Shouldn't this simply be "Counter and accumlator variables are created in instance data to sum a selection of values chosen by the user." ?? "11.2 The xforms-submit Event" In "The response returned from the submission is applied as follows:" list, the second bullet's second sentence "if the parse fails ..." should start uppercase. "11.19.3 SOAP HTTP Binding" In the second list the first bullet "the Content-type HTTP header is change to text/xml" should be changed to contain "changed". Regards, Uli. -- Ulrich Nicolas Lissé
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Uli, Thanks for spotting these issues. Resolutions are given in the inline comments. 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. Thanks, John Boyer > > Hello John, > > great work. Alas, some typos and other minor issues popped up during > fine reading. Maybe some of these are contained in XForms 1.0 editions > too, but I didn't check this. > > "3.3 The XForms Core Module" > > The table contains a wrong attribute definition for the submission > element. It says: "... method > ("post"|"get"|"put"|delete|"form-data-post"|"urlencoded-post"|QNameButNotNCNAME) > > ...." Fixed. > > The word delete should have double quotes, since it is a fixed value > instead of a type. > > "3.3.1 The model Element" > > The sentence "This element is not an XForms Action, and has no > predefined behavior event-based behavior." has too many behaviors ;-) > Remove "behavior" after "predefined". > The whole phrase containing the error is removed as it is ambiguous even once the error is corrected. > "3.3.2 The instance Element" > > In the description of the resource attribute there is the sentence "If > the host language may treat failure to traverse the link as an exception > (4.5.2 The xforms-link-exception Event).", which is not really > understandable. Remove "If". Fixed via changes to allow the src attribute into XForms directly (as opposed to being added by the host language). > > "4.5.5 The xforms-version-exception Event" > > For this event's context information a property "errorinformation" is > defined. Shouldn't this be named "error-information" instead to be > consistent with the naming scheme of other event's properties (like > "resource-uri" or "error-message")? Fixed. > > "4.6.1 For input, secret, textarea, range, or upload Controls" > > The first bullet says "... has the "incremental="true" setting ...", the > second "... does not have the "incremental=true" setting". The double > quotes for the incremental attribute have to be fixed, and it should be > set in <code>-markup. > Fixed. > "4.6.3 For select or select1 Controls" > > Same as above. Fixed. > > "7.6 The XForms Function Library" > > Replace "xforms-binding exception" with "xforms-binding-exception" in > the last sentence. Fixed. > > "7.8.5 The index() Function" > > The second sentence "if the specified argument ..." should start uppercase. > Fixed. > "7.9.4 The digest() Function" > > All three expamples for this extension function still show > "hash-encode". Replace with "digest". > Good catch. Fixed. > "8.1.5 The output Element" > > There are two Description paragraphs provided here. They are similar but > not identical. The second one seems more accurate, so please delete the > first one. > Fixed. > "8.3.1 The filename Element" > > In the description of a then following example > "mail/attachment@filename" and "mail/attachment@mediatype" refer to > attribute nodes. The correct XPath syntax "mail/attachment/@filename" > and "mail/attachment/@mediatype" should be used. > Good catch. Fixed. > "9.3.1 The repeat Element" > > In the paragraph after the special attributes description the second > sentence "if an element of the collection ..." should start uppercase. > Fixed. > "9.3.5 The insert Action" > > The 5th example ("Inserting into a repeat, whether or not it is empty") > refers to "repeat R". In the code snippet there is a call to index() > function in <xf:insert ... at="index('R')"/> as well as a <xf:setfocus > control="R"/>. However, the repeat is missing id="R" which might confuse > readers. Maybe it could even be renamed to something more > self-explanatory, e.g. "PurchaseOrderRepeat". > Added id="R" > "9.3.7 The setindex Element" > > In the paragraph after the special attributes description the third > sentence "if the index evaluates to NaN ..." should start uppercase. > Fixed. > "9.3.8 Repeat Processing" > > In list item 2. the second sentence "if the initial startindex ..." > should start uppercase. > Fixed. > "10.10.2 Processing of the load Action" > > In the second paragraph "... link between th load element and the remote > resource" replace "th " with "the ". Fixed. > > "10.15 Iteration of XForms Actions" > > I don't speak English natively, but the sentence "Counter and Accumlator > Variables are Created in Instance Data to Sum a Selection of Values > Chosen by the User" hurts my eyes. Shouldn't this simply be "Counter and > accumlator variables are created in instance data to sum a selection of > values chosen by the user." ?? > You're right. It's not a title, so it shouldn't be in title case. Fixed. > "11.2 The xforms-submit Event" > > In "The response returned from the submission is applied as follows:" > list, the second bullet's second sentence "if the parse fails ..." > should start uppercase. > Fixed. > "11.19.3 SOAP HTTP Binding" > > In the second list the first bullet "the Content-type HTTP header is > change to text/xml" should be changed to contain "changed". Fixed. > > Regards, > Uli. > -- > Ulrich Nicolas Liss銾 > >
PROBLEM ID: 76
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> 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, '/')" ... /> @method The allowable values should be listed. @verb Very difficult to understand what this does, and what a verb is. What are the allowable vaues? Note that the names @validate and @serialize are verbs, while @relevant is an adjective (untidy difference). All the attributes need types and default values here.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> 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.
PROBLEM ID: 103
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> This is a LC comment regarding the "verb" section of http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-verb and likewise references in http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-options 1) I can not find a clear definition or normative reference, to what a "verb" is. 2) Section states: "default value is determined based on the URI scheme and the method attribute using the rules in 11.9 Submission Options. " Comment: Looking in 11.9, I can not find any clear rules for processing. Only a reference to the "submission" column, which does not define a string literal that can be used for the value of the element/attribute of verb. I'd recommend clarifying the table either by adding a new "Verb" column and string literals that are valid. 3) Section states: "For example, under the http and https schemes, the methods post and urlencoded-post correspond to the verb POST" Comment: Does this imply that if action="http://someurl" that verb="post" and if action="https://someurl" then verb="urlencoded-post"? 4) Section states: "If given, the verb attribute overrides the default verb used in submission" Comment: What is the default? Perhaps it is given in the table in 11.9 but I'm unable to clearly map the values 5) Editorial Section states: "The submission element can optionally *have* a child element named verb" missing word *have* Thanks, Steve Speicher IBM SWG, Software Standards
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steve, Thank you for the last call comments below, all of which have been accepted and implemented in the ways described in the inline comments below. Please see the editor's draft available from the Forms WG website and let us know if you have any further concerns. Best regards, John Boyer > > This is a LC comment regarding the "verb" section of > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-verb > and likewise references in > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-options > > 1) I can not find a clear definition or normative reference, to what a > "verb" is. > We eliminated verb in favor of better use of method attr/elem pair since method is normatively defined by RFC 2616. > 2) > Section states: > "default value is determined based on the URI scheme and the > method attribute using the rules in 11.9 Submission Options. " > Comment: > Looking in 11.9, I can not find any clear rules for processing. > Only a reference to the "submission" column, which does not define a > string literal that can be used for the value of the element/attribute of > verb. I'd recommend clarifying the table either by adding a new "Verb" > column and string literals that are valid. > 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 several places in the submission chapter, esp. the table in 11.9, so that the relationship between the method, the default serialization and the submission protocol operation (e.g. the http method) should now be clear . > 3) > Section states: > "For example, under the http and https schemes, the methods post > and urlencoded-post correspond to the verb POST" > Comment: > Does this imply that if action="http://someurl" that verb="post" > and if action="https://someurl" then verb="urlencoded-post"? > 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) > Section states: > "If given, the verb attribute overrides the default verb used in > submission" > Comment: > What is the default? Perhaps it is given in the table in 11.9 but > I'm unable to clearly map the values > 4) Now that we have switched to using 'method' instead of 'verb', it is clear that there is no default (specifying the submission method is mandatory). > 5) Editorial > Section states: > "The submission element can optionally *have* a child element > named verb" > missing word *have* > 5) The child element has been renamed 'method', but error reported here is fixed. > Thanks, > Steve Speicher > IBM SWG, Software Standards > > >
PROBLEM ID: 83
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, I have a doubt about the meaning of "empty" in the wording "required but empty" (which appears in 11.2.3 and 4.3.5). It seems that "empty" could either mean: 1. A zero-length string (clear technical interpretation) 2. A string empty as per #1 above, or a string with only white-space (human-friendly interpretation) Imagine a user entering by error a space in an input field. Visually, with most agents (typically web browsers), you can't tell whether the field is empty according to #1 above, or contains white space. So to the user, the field is "empty". But if the XForms implementation implements #1, then this visually empty field will be considered non-empty, and pass submission even if required. This would favor an interpretation of "empty" where not only strictly empty strings are "empty", but also strings containing only white space. At the very least, the spec should say whether it means #1, #2, or implementation-dependent. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, The working group considered this issue and felt that the definition of empty string as being zero characters (as opposed to zero non-whitespace characters) was well-known enough not to need clarification and that this is the definition that we should be using for the 'required' MIP as it is consistent with the notion of empty string in XML schema and XPath. We do agree that there are forms in which one might not want to distinguish empty from containing only whitespace. We believe this can be done via the constraint MIP, though we agree with your statement in [1] that it is reasonable to consider how this capability might be more simply accessed in a future version of XForms. [1] http://lists.w3.org/Archives/Public/public-forms/2007Jul/0078.html Thank you, John Boyer > > All, > > I have a doubt about the meaning of "empty" in the wording "required but > empty" (which appears in 11.2.3 and 4.3.5). > > It seems that "empty" could either mean: > > 1. A zero-length string (clear technical interpretation) > 2. A string empty as per #1 above, or a string with only white-space > (human-friendly interpretation) > > Imagine a user entering by error a space in an input field. Visually, > with most agents (typically web browsers), you can't tell whether the > field is empty according to #1 above, or contains white space. So to the > user, the field is "empty". > > But if the XForms implementation implements #1, then this visually empty > field will be considered non-empty, and pass submission even if required. > > This would favor an interpretation of "empty" where not only strictly > empty strings are "empty", but also strings containing only white space. > > At the very least, the spec should say whether it means #1, #2, or > implementation-dependent. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 163
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222 2) The Submission module is sufficiently getting more complex but found very few examples, I'd recommend adding a few. Thanks, Steve Speicher IBM SWG, Software Standards
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Steve, We will add submission examples to the spec. Regards, Nick Van den Bleeken > > LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222 > > 2) The Submission module is sufficiently getting more complex but found > very few examples, I'd recommend adding a few. > > Thanks, > Steve Speicher > IBM SWG, Software Standards > >
PROBLEM ID: 81
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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".
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#submit-options Presumably for each entry there is a corresponding default verb. Why not add it as a column to the table.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, 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". We believe this solution satisfies the intent of your feedback in this last call issue. 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 this issue. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#submit-options > > Presumably for each entry there is a corresponding default verb. Why > not add it as a column to the table. > >
PROBLEM ID: 4
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> LC comment on http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-header Section states: "The submission element can contain zero or more header child elements, which must appear immediately after the optional resource and verb elements." What happens when this occurs: <submission> <resource>...</resource> <header>...</header> <verb>...</verb> <header>...</header> </submission> Should this dispatch some fatal error? Should the <verb> be ignorred? Should the first <header> be ignorred? Why is this order important? I can possibly see how resource and verb may conflict but not sure about header. This comment also indirectly applies to 11.6 <resource>, which states "first child of submission" and 11.7.2 verb element, which says "immediately after optional resource element". As far as handling of these items if out of order. Thanks, Steve Speicher IBM SWG, Software Standards
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Steve, We accepted your comments and we are going to relax the order of the elements. Regards, Nick Van den Bleeken > > LC comment on > http://www.w3.org/TR/2007/WD-xforms11-20070222/#submit-header > > Section states: "The submission element can contain zero or more header > child elements, which must appear immediately after the optional resource > and verb elements." > > What happens when this occurs: > <submission> > <resource>...</resource> > <header>...</header> > <verb>...</verb> > <header>...</header> > </submission> > > Should this dispatch some fatal error? > Should the <verb> be ignorred? > Should the first <header> be ignorred? > > Why is this order important? I can possibly see how resource and verb may > conflict but not sure about header. > > This comment also indirectly applies to 11.6 <resource>, which states > "first child of submission" and 11.7.2 verb element, which says > "immediately after optional resource element". As far as handling of > these items if out of order. > > Thanks, > Steve Speicher > IBM SWG, Software Standards > > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Aaron, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > > I know that this is a nit, but its been noticed by a couple of us on the > Mozilla project already so I might as well mention it. > > In section 11.6 it says, "If the submission does not have a resource > element as its first child, then the submission URI is obtained from the > resource attribute or the action attribute." > > I assume that this means that if submission does not have a resource > element as its first child ELEMENT, then the other rules apply. The first > child node will quite often be a text node if submission and resource are > on separate lines as they will most likely be in the real world. So > perhaps this line should be changed to reflect the element aspect. > > --Aaron > IBM Corporation > Internal Zip: 9022D016 > 11501 Burnet Road > Austin, TX 78758 > (512)838-9948 > inet: aaronr@us.ibm.com > _ > (} @ > |= Volleyball Rules!!! > /\ > >
PROBLEM ID: 78
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#submit-verb "The submission element must allow a new optional attribute named verb of type string." Must allow? Anyway, we now have the following possibilities: <submit verb="PUT"/> <submit><verb value="'PUT'"/></submit> <submit><verb>PUT</verb></submit> Isn't this overkill? Proposal: Since it is entirely new, use @verb as a value attribute <submit verb="../method/verb"/> Drop the verb child element.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, We agree that there are more possibilities than there should be. However, the verb elem/attr pair were eliminated. Instead, we now have he method element to provide an XPath expr in lieu of the literal value in the method attr, which is a pre-existing literal-valued method attribute. 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. 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 this issue. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#submit-verb > > "The submission element must allow a new optional attribute named verb of > type string." > > Must allow? > > Anyway, we now have the following possibilities: > > <submit verb="PUT"/> > <submit><verb value="'PUT'"/></submit> > <submit><verb>PUT</verb></submit> > > Isn't this overkill? > > Proposal: > Since it is entirely new, use @verb as a value attribute > <submit verb="../method/verb"/> > Drop the verb child element. > > >
PROBLEM ID: 54
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> I know that this is a nit, but its been noticed by a couple of us on the Mozilla project already so I might as well mention it. In section 11.6 it says, "If the submission does not have a resource element as its first child, then the submission URI is obtained from the resource attribute or the action attribute." I assume that this means that if submission does not have a resource element as its first child ELEMENT, then the other rules apply. The first child node will quite often be a text node if submission and resource are on separate lines as they will most likely be in the real world. So perhaps this line should be changed to reflect the element aspect. --Aaron IBM Corporation Internal Zip: 9022D016 11501 Burnet Road Austin, TX 78758 (512)838-9948 inet: aaronr@us.ibm.com _ (} @ |= Volleyball Rules!!! /\
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Aaron, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > > I know that this is a nit, but its been noticed by a couple of us on the > Mozilla project already so I might as well mention it. > > In section 11.6 it says, "If the submission does not have a resource > element as its first child, then the submission URI is obtained from the > resource attribute or the action attribute." > > I assume that this means that if submission does not have a resource > element as its first child ELEMENT, then the other rules apply. The first > child node will quite often be a text node if submission and resource are > on separate lines as they will most likely be in the real world. So > perhaps this line should be changed to reflect the element aspect. > > --Aaron > IBM Corporation > Internal Zip: 9022D016 > 11501 Burnet Road > Austin, TX 78758 > (512)838-9948 > inet: aaronr@us.ibm.com > _ > (} @ > |= Volleyball Rules!!! > /\ > >
PROBLEM ID: 1
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Mark Birbeck" <mark.birbeck@x-port.net> On the call yesterday, John suggested that one way to achieve the use-case I would like (of allowing a submission that does not send any instance data to not require validation) could be achieved by making the @relevant and @validate attributes *default* to the value in @serialize. I think this is a neat solution, and gives the author flexibility. So, proposed wording to go section 11.1, would be: --- STARTS --- validate Optional boolean attribute that indicates whether or not the data validation checks of the submission are performed. The default value is the value of serialize, if present, or "true", otherwise. relevant Optional boolean attribute that indicates whether or not the relevance pruning of the submission is performed. The default value is the value of serialize, if present, or "true", otherwise. serialize Optional boolean attribute with default "true" that indicates whether or not the instance data is serialized as part of the submission. This can be useful for requests that either require no data or that have the data already gathered in the URI. Note that that setting serialize to false will also have the effect of preventing relevance pruning and validation. The author is free to override this by setting relevant and/or validate to "true". --- ENDS --- On 14/02/07, Mark Birbeck <mark.birbeck@x-port.net> wrote: > The @serialize attribute seems to be a useful way of doing this: > > <xf:submission > ref="/IHaveNoDataToSendIJustWantToUseSubmission" > method="get" action="..." > /> > > i.e.: > > <xf:submission > serialize="false" > method="get" action="..." > /> > > However, because @serialize is not referred to until step 7 in 11.2, > the processor will already have gone through relevance filtering and > validity testing. Also, if there were no node to serialise from, step > 2 would actually fail, despite the fact that the author actually > doesn't want to serialise anything. > > Is it possible we can harmonise the two more, so that serialize can be > used to indicate that you don't want to send any data, but you do want > to use the whole submission infrastructure. This is particularly > common when using a REST design, since a GET on a URL is all you need > to do to get a resource. Likewise picking up RSS feeds. > > Perhaps a modification to step 2 along these lines is all that's needed: > > A node from the instance data is selected, based on attributes on > the submission element. <add>If the value of serialize is false, > processing continues at step 4, with no data selected.</add> If the > attributes of submission select an empty nodeset... > > Regards, > > Mark > > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > -- Mark Birbeck, formsPlayer mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks Mark. We accepted and made this change at the FtF 2007-06-13. Best wishes, Steven Pemberton > On the call yesterday, John suggested that one way to achieve the > use-case I would like (of allowing a submission that does not send any > instance data to not require validation) could be achieved by making > the @relevant and @validate attributes *default* to the value in > @serialize. I think this is a neat solution, and gives the author > flexibility. > > So, proposed wording to go section 11.1, would be: > > --- STARTS --- > > validate > > Optional boolean attribute that indicates whether or not the data > validation checks of the submission are performed. The default value > is the value of serialize, if present, or "true", otherwise. > > relevant > > Optional boolean attribute that indicates whether or not the > relevance pruning of the submission is performed. The default value is > the value of serialize, if present, or "true", otherwise. > > serialize > > Optional boolean attribute with default "true" that indicates > whether or not the instance data is serialized as part of the > submission. This can be useful for requests that either require no > data or that have the data already gathered in the URI. Note that that > setting serialize to false will also have the effect of preventing > relevance pruning and validation. The author is free to override this > by setting relevant and/or validate to "true". > > --- ENDS --- > > On 14/02/07, Mark Birbeck <mark.birbeck@x-port.net> wrote: >> The @serialize attribute seems to be a useful way of doing this: >> >> <xf:submission >> ref="/IHaveNoDataToSendIJustWantToUseSubmission" >> method="get" action="..." >> /> >> >> i.e.: >> >> <xf:submission >> serialize="false" >> method="get" action="..." >> /> >> >> However, because @serialize is not referred to until step 7 in 11.2, >> the processor will already have gone through relevance filtering and >> validity testing. Also, if there were no node to serialise from, step >> 2 would actually fail, despite the fact that the author actually >> doesn't want to serialise anything. >> >> Is it possible we can harmonise the two more, so that serialize can be >> used to indicate that you don't want to send any data, but you do want >> to use the whole submission infrastructure. This is particularly >> common when using a REST design, since a GET on a URL is all you need >> to do to get a resource. Likewise picking up RSS feeds. >> >> Perhaps a modification to step 2 along these lines is all that's needed: >> >> A node from the instance data is selected, based on attributes on >> the submission element. <add>If the value of serialize is false, >> processing continues at step 4, with no data selected.</add> If the >> attributes of submission select an empty nodeset... >> >> Regards, >> >> Mark >> >> >> -- >> Mark Birbeck, formsPlayer >> >> mark.birbeck@x-port.net | +44 (0) 20 7689 9232 >> http://www.formsPlayer.com | http://internet-apps.blogspot.com >> >> standards. innovation. >> > > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, 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". We believe this solution satisfies the intent of your feedback in this last call issue. 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 this issue. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#submit-options > > Presumably for each entry there is a corresponding default verb. Why > not add it as a column to the table. > >
PROBLEM ID: 46
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 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? 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. 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. 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? 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? 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!!! /\
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> 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!!! > /\ > >
PROBLEM ID: 80
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#submit-header This seems over-engineered. Why not instead of <header nodeset="..."> <name value=".../> <value value="..."/> </header use the simpler: <header nodeset="..." name="..." value="..."/>
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, Thank you very much for considering this issue. In this case, the working group did not implement a change based on the feedback, and I will now endeavor to explain why. 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 the specification of multiple 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. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#submit-header > > This seems over-engineered. Why not instead of > > <header nodeset="..."> > <name value=".../> > <value value="..."/> > </header > > use the simpler: > > <header nodeset="..." name="..." value="..."/> > > >
PROBLEM ID: 77
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#submit-resource "The URI to be used by the submission can be specified with either the value attribute or the string content of the resource element." So we now have the following equivalent possibilities: <submit action="http://examples.org/search"/> <submit resource="http://examples.org/search"/> <submit><resource value="'http://examples.org/search'"/></submit> <submit><resource>http://examples.org/search</resource></submit> Isn't this overkill? Proposal: Keep @action for the literal case Use @resource as a value attribute <submit resource="concat('http://', site, '/', command)"/> Drop the resource child.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The Forms WG agrees that it is confusing and 'overkill' to have both an action and a resource attribute. The resolution in this case was to clearly mark the action attribute as deprecated (supported, but not the preferred attribute to use anymore). There are two reasons for this. First, the term 'action' in XForms is already used to describe event handlers, so discussions of submission have been confusing because one can also have actions that handle various submission events. Switching to a resource attribute clears up that ambiguity. Second, the WG decided to consistently use the attribute name 'resource' as it is used elsewhere in XForms (the load action and the instance element). Regarding the suggestion to let resource be an XPath expression since we already have action for the literal case, the above resolution clarifies that the intent is to have resource be used in lieu of action. For consistency with the use of the resource attribute in the load action and the instance element, the datatype must be an xsd:anyURI. Also, for consistency with how XPath expressions are provided to other attributes in XForms 1.1, the resource child element is provided. Please see the editor's draft of the specification available from the Forms WG home page and let us know if you have any further concerns about this issue. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#submit-resource > > "The URI to be used by the submission can be specified with either the > value attribute or the string content of the resource element." > > So we now have the following equivalent possibilities: > > <submit action="http://examples.org/search"/> > <submit resource="http://examples.org/search"/> > <submit><resource value="'http://examples.org/search'"/></submit> > <submit><resource>http://examples.org/search</resource></submit> > > Isn't this overkill? > > Proposal: > Keep @action for the literal case > Use @resource as a value attribute > <submit resource="concat('http://', site, '/', command)"/> > Drop the resource child. > > >
PROBLEM ID: 79
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#submit-evt-submit Contains the sentence "action processing is blocked within in the default processing" which has "within in"
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > http://www.w3.org/TR/xforms11/#submit-evt-submit > > Contains the sentence "action processing is blocked within in the > default processing" which has "within in" > >
PROBLEM ID: 10
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 6 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 5.2.5 Restriction of international mail addresses unclear Comment: Internationalized email addresses are not restricted by XForms beyond the definition in the RFC. Please clarify whether it is possible to use internationalized email or not. We feel that it would be important that it is possible.
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thank you for this comment. It has sparked an animated discussion about whether the lexical values or the ascii values for international email addresses should be stored in the XForms instances. We have come to the conclusion that it should be the lexical values, rather than the regular expression used in 5.2.5 of the XForms 1.1 spec. However, we would value your advice on the correct regular expression for an international email address. Would you be willing to help us with that? Many thanks. Best wishes, Steven Pemberton For the Forms WG > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 6 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 5.2.5 > Restriction of international mail addresses unclear > > Comment: > > Internationalized email addresses are not restricted by XForms beyond the > definition in the RFC. > > Please clarify whether it is possible to use internationalized email or > not. We feel that it would be important that it is possible. > > > > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> We have decided that we will defer the issue about international mail addresses to a future XForms version, where i18mail can be defined and keep current pattern definition of XForms email. Due to the fact that we are able to define the schema type of an international mail addresses today. Regards, Nick Van den Bleeken > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 6 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 5.2.5 > Restriction of international mail addresses unclear > > Comment: > > Internationalized email addresses are not restricted by XForms beyond the > definition in the RFC. > > Please clarify whether it is possible to use internationalized email or > not. We feel that it would be important that it is possible. > > > > >
PROBLEM ID: 136
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> A. It seems odd that xs:double is not included in the core subset since it's the only numeric data type supported by XPath 1.0
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Thanks for the comment. In fact we have removed the information about the smaller conformance profile since it is not relevant to this specification. XForms Basic (a different specification) doesn't include double at present, but we anticipate that it will be added to a future version. Best wishes, Steven Pemberton For the Forms WG > A. It seems odd that xs:double is not included in the core subset > since it's the only numeric data type supported by XPath 1.0
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for the comment. In fact we have removed the information about the smaller conformance profile since it is not relevant to this specification. XForms Basic (a different specification) doesn't include double at present, but we anticipate that it will be added to a future version. Best wishes, Steven Pemberton For the Forms WG > A. It seems odd that xs:double is not included in the core subset > since it's the only numeric data type supported by XPath 1.0
PROBLEM ID: 138
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
Essentially duplicate of issue types/22. We are rewriting the paragrqaph to take away the confusion.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> C. It's not clear which of these data types allow empty content and which don't. What is meant by "the indicated datatypes"? Also, there should be a more formal definition of these types, for example they could be defined either as a union of the base type with a zero-length string, or as a list of zero-or-one items of the base type. Such a definition affects the semantics of XPath expressions applied to values of these types. We do not understand paragraph 2, which appears to contradict paragraph 1.
FOLLOWUP 1:
From: "Michael Kay" <mike@saxonica.com> Thanks. From the point of view of typed XPath processing, a list of length 0-or-1 is probably preferable to a union-with-"". For example, sum() in the list case would ignore empty values, whereas in the union case it would give a type error because an empty value is treated as a string. Similarly x[@a > 3] would effectively ignore empty values of @a if treated as a list, but give a type error if treated as a union. From a validation perspective, of course, there is no difference. Michael Kay > -----Original Message----- > From: Steven Pemberton [mailto:xforms-issues@mn.aptest.com] > Sent: 14 June 2007 21:14 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: Section 5.2.7 (PR#138) > > Thanks for the comment. In fact the introductory paragraph > confused even us when we reread it :-) > > We are rewriting this paragraph to make it clear that all > datatypes here allow empty content. They will indeed be > defined as unions in the Schema for XForms 1.1. > > Best wishes, > > Steven Pemberton > For the Forms WG > > > C. It's not clear which of these data types allow empty > content and > > which don't. What is meant by "the indicated datatypes"? Also, > > there should be a more formal definition of these types, for > > example they could be defined either as a union of the base type > > with a zero-length string, or as a list of zero-or-one > items of the > > base type. Such a definition affects the semantics of XPath > > expressions applied to values of these types. We do not > understand > > paragraph 2, which appears to contradict paragraph 1. > > > > > >
FOLLOWUP 2:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Thanks for the comment. In fact the introductory paragraph confused even us when we reread it :-) We are rewriting this paragraph to make it clear that all datatypes here allow empty content. They will indeed be defined as unions in the Schema for XForms 1.1. Best wishes, Steven Pemberton For the Forms WG > C. It's not clear which of these data types allow empty content and > which don't. What is meant by "the indicated datatypes"? Also, > there should be a more formal definition of these types, for > example they could be defined either as a union of the base type > with a zero-length string, or as a list of zero-or-one items of the > base type. Such a definition affects the semantics of XPath > expressions applied to values of these types. We do not understand > paragraph 2, which appears to contradict paragraph 1. > > >
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for the comment. In fact the introductory paragraph confused even us when we reread it :-) We are rewriting this paragraph to make it clear that all datatypes here allow empty content. They will indeed be defined as unions in the Schema for XForms 1.1. Best wishes, Steven Pemberton For the Forms WG > C. It's not clear which of these data types allow empty content and > which don't. What is meant by "the indicated datatypes"? Also, > there should be a more formal definition of these types, for > example they could be defined either as a union of the base type > with a zero-length string, or as a list of zero-or-one items of the > base type. Such a definition affects the semantics of XPath > expressions applied to values of these types. We do not understand > paragraph 2, which appears to contradict paragraph 1. > > >
PROBLEM ID: 6
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 1 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 5.2 Lexical space for XForms data types missing Comment: The description of the XForms data types does not in every case provide information about the lexical space(s), but only about the value spaces. Please provide a statement describing the relation.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Thanks for the comment. In fact we have removed the information about the smaller conformance profile since it is not relevant to this specification. XForms Basic (a different specification) doesn't include double at present, but we anticipate that it will be added to a future version. Best wishes, Steven Pemberton For the Forms WG > A. It seems odd that xs:double is not included in the core subset > since it's the only numeric data type supported by XPath 1.0
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> We agree. Although there is some text in section 8 on controls, suggesting the difference between the two, we agree that it should be made clear in section 5 on datatypes as well. Thanks you for the comment. Best wishes, Steven Pemberton For the Forms WG > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 1 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 5.2 > Lexical space for XForms data types missing > > Comment: > > The description of the XForms data types does not in every case provide > information about the lexical space(s), but only about the value spaces. > Please provide a statement describing the relation.
REPLY 2:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Thanks for the comment. In fact we have removed the information about the smaller conformance profile since it is not relevant to this specification. XForms Basic (a different specification) doesn't include double at present, but we anticipate that it will be added to a future version. Best wishes, Steven Pemberton For the Forms WG > A. It seems odd that xs:double is not included in the core subset > since it's the only numeric data type supported by XPath 1.0
PROBLEM ID: 48
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "John Cowan" <cowan@ccil.org> The XML Core WG (for which I am speaking officially) has found the following six issues with the Last Call draft of XForms 1.1: 1) XForms inherits the definition of "id" from the language in which it is embedded; as such, it cannot be readily embedded in a language where the ID attribute is "xml:id". Either should be allowed. 2) There is a normative reference to XForms 1.0 that seems unnecessary, as XForms 1.1 is self-contained. 3) The types xforms:dayTimeDuration and yearMonthDuration should be moved to the list of datatypes that allow empty content in 5.2.7, and their places should be occupied by the types xs:dayTimeDuration and xs:yearMonthDuration. These types are in the XML Schema namespace, but are defined by the XQuery 1.0/XSLT 2.0 data model. 4) xs: seems to be preferred to xsd: as the prefix for the XML Schema namespace; xsd: suggests the XML Schema Datatypes namespace. 5) The XForms-specific procedures should be harmonized with the XPath 2.0 function library where possible. 6) XForms 1.1 refers to the standard ISO/IEC 7812-1 normatively in order to define the credit card checksum algorithm. This standard is available only for money, and we think the algorithm should be restated in XForms 1.1 and the reference changed to an informative one. The algorithm itself is in the public domain; an adequate specification of it can be found at http://en.wikipedia.org/wiki/Luhn_algorithm . -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> > The XML Core WG (for which I am speaking officially) has found the > following six issues with the Last Call draft of XForms 1.1: > > 1) XForms inherits the definition of "id" from the language in which it > is embedded; as such, it cannot be readily embedded in a language where > the ID attribute is "xml:id". Either should be allowed. > We added a note to Common Attributes: "Elements can be identified using any attribute of type ID (such as xml:id), not just the id attribute defined above." > 2) There is a normative reference to XForms 1.0 that seems unnecessary, > as XForms 1.1 is self-contained. > We moved XForms 1.0 to a informative reference. > 3) The types xforms:dayTimeDuration and yearMonthDuration should be > moved to the list of datatypes that allow empty content in 5.2.7, > and their places should be occupied by the types xs:dayTimeDuration > and xs:yearMonthDuration. These types are in the XML Schema namespace, > but are defined by the XQuery 1.0/XSLT 2.0 data model. > We cannot move xforms:dayTimeDuration and xforms:yearMonthDuration to the xs: types from XQuery 1.0 / XSLT 2.0 because XForms 1.1 is based on XML Schema 1.0 and XPath 1.0. > 4) xs: seems to be preferred to xsd: as the prefix for the XML Schema > namespace; xsd: suggests the XML Schema Datatypes namespace. > We change xsd:schema and children to xs:schema and children, and add a definition of the xs: namespace, but leave occurrences the definition xmlns:xsd="http://www.w3.org/2001/XMLSchema" and the uses on datatypes, because that's what XML Schema Part 0 does. Implementors will already note that XML Schema requires handling of type definitions in the xmlns:xsd="http://www.w3.org/2001/XMLSchema-datatypes" namespace without special instruction from XForms. > 5) The XForms-specific procedures should be harmonized with the XPath > 2.0 function library where possible. > We agree that XForms-specific procedures should be harmonized with XPath 2.0 functions library where possible. > 6) XForms 1.1 refers to the standard ISO/IEC 7812-1 normatively in order > to define the credit card checksum algorithm. This standard is available > only for money, and we think the algorithm should be restated in XForms 1.1 > and the reference changed to an informative one. The algorithm itself > is in the public domain; an adequate specification of it can be found > at http://en.wikipedia.org/wiki/Luhn_algorithm . > We change the Luhn reference from ISO/IEC 7912-1 to expired patent "U.S. PATENT 2,950,048 Computer for Verifying Numbers.", H.P. Luhn. We change terminology from "Luhn formula" to "Luhn algorithm" to make finding the Wikipedia entry easy. We retain "Luhn function" for now. > -- > Unless it was by accident that I had John Cowan > offended someone, I never apologized. cowan@ccil.org > --Quentin Crisp http://www.ccil.org/~cowan > > Regards, Ulrich Nicolas Lissé. For the Forms WG
PROBLEM ID: 137
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response
NOTES:
RESOLUTION: Stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> B. dayTimeDuration and yearMonthDuration are now available in the XML Schema namespace. We encourage you to adopt these new types.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, The Forms Working group resolved to change the specification to make it clearer that XML schema 1.0 only datatypes are supported in XForms 1.1. XForms already subtracts four datatypes from that list, so it did not make as much sense for us to then add two datatypes not in schema 1.0 considering that is the spec we normatively reference. Note, however, that these types could be added to any XForm by using a schema. Also, the default datatypes available without using a schema already make available these two kinds of durations, except they also allow empty content into the lexical space by default. Hence, the exact datatype can be achieved by using the xforms defined datatypes in combination with the required model item property. We hope that this information explains why we did not adopt these datatypes for XForms 1.1. Thank you, John Boyer > > > > B. dayTimeDuration and yearMonthDuration are now available in the > XML Schema namespace. We encourage you to adopt these new types. > > > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Michael, The Forms Working group resolved to change the specification to make it clearer that XML schema 1.0 only datatypes are supported in XForms 1.1. XForms already subtracts four datatypes from that list, so it did not make as much sense for us to then add two datatypes not in schema 1.0 considering that is the spec we normatively reference. Note, however, that these types could be added to any XForm by using a schema. Also, the default datatypes available without using a schema already make available these two kinds of durations, except they also allow empty content into the lexical space by default. Hence, the exact datatype can be achieved by using the xforms defined datatypes in combination with the required model item property. We hope that this information explains why we did not adopt these datatypes for XForms 1.1. Thank you, John Boyer > > > > B. dayTimeDuration and yearMonthDuration are now available in the > XML Schema namespace. We encourage you to adopt these new types. > > > >
PROBLEM ID: 98
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#email-type http://www.w3.org/TR/xforms11/#id-card-type All the other xforms: datatypes allow empty as a value. These two don't, and I think this is just an oversight. Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group agrees that all XForms-defined datatypes allow empty content, and the specification has been amended to reflect this. Please see the updated version available from the editor's draft links on the Forms WG homepage. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#email-type > http://www.w3.org/TR/xforms11/#id-card-type > > All the other xforms: datatypes allow empty as a value. These two don't, > and I think this is just an oversight. > > Steven > >
PROBLEM ID: 7
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response
NOTES:
RESOLUTION : We stick with types defined in schema 1.0 and add new types when we transition to later versions of schema
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 2 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 5.2.3 and 5.2.4 Reference to definition of data types missing Comment: The data types dateTimeDuration and yearMonthDuration are described as XForms data types, but they are data types defined in the XQuery Data Model [http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/] specification. Please provide a reference to this specification from sec. 5.2.3 and 5.2.4. See also the related comment from the XML Core WG [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0007.html] , which is basically the same.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, The Forms Working group resolved to change the specification to make it clearer that XML schema 1.0 only datatypes are supported in XForms 1.1. XForms already subtracts four datatypes from that list, so it did not make as much sense for us to then add two datatypes not in schema 1.0 considering that is the spec we normatively reference. Note, however, that these types could be added to any XForm by using a schema. Also, the default datatypes available without using a schema already make available these two kinds of durations, except they also allow empty content into the lexical space by default. Hence, the exact datatype can be achieved by using the xforms defined datatypes in combination with the required model item property. We hope that this information explains why we did not adopt these datatypes for XForms 1.1. Thank you, John Boyer > > > > B. dayTimeDuration and yearMonthDuration are now available in the > XML Schema namespace. We encourage you to adopt these new types. > > > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Felix, The working group considered this issue and decide to leave the datatype definitions in the XForms namespace for three reasons. First, XForms is based on XML Schema 1.0, so new types will be added to a future version of XForms when an updated version of XML schema is adopted. Second, datatypes in the XForms namespace are more convenient for form authors because they do not have to be namespace qualified in 'type' MIPs. Third, the XForms versions actually are differeent because they also permit empty strings, which is also more convenient for form authoring. Generally, the latter two reasons are particularly important as they explain why all the xsd simple types have corresponding xforms datatypes. XML schema has the mindset of validating a "full" schema instance, i.e. data that is about to be processed by a server-side business process. This is a bit of a technological mismatch for forms, which describe the process for getting from "empty" schema instance to "full" schema instance. I hope you find this rationale satisfactory. Best regards, John Boyer > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 2 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 5.2.3 and 5.2.4 > Reference to definition of data types missing > > Comment: > > The data types > dateTimeDuration > and > yearMonthDuration > are described as XForms data types, but they are data types defined in the > XQuery Data Model [http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/] > specification. Please provide a reference to this specification from sec. > 5.2.3 and 5.2.4. See also the > related comment from the XML Core WG > [http://lists.w3.org/Archives/Public/www-forms-editor/2007Mar/0007.html] > , which is basically the same. > > > > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, These have been done and can now be found in the editor's draft available from the working group home pages. Best regards, John Boyer > > > http://www.w3.org/TR/xforms11/#email-type > > Please add to the "Examples of invalid xforms:email addresses" > > mailto:editors@example.com > > (and point out, maybe, that this is a valid anyURI) > > Steven > >
REPLY 3:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Michael, The Forms Working group resolved to change the specification to make it clearer that XML schema 1.0 only datatypes are supported in XForms 1.1. XForms already subtracts four datatypes from that list, so it did not make as much sense for us to then add two datatypes not in schema 1.0 considering that is the spec we normatively reference. Note, however, that these types could be added to any XForm by using a schema. Also, the default datatypes available without using a schema already make available these two kinds of durations, except they also allow empty content into the lexical space by default. Hence, the exact datatype can be achieved by using the xforms defined datatypes in combination with the required model item property. We hope that this information explains why we did not adopt these datatypes for XForms 1.1. Thank you, John Boyer > > > > B. dayTimeDuration and yearMonthDuration are now available in the > XML Schema namespace. We encourage you to adopt these new types. > > > >
PROBLEM ID: 135
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steve K Speicher" <sspeiche@us.ibm.com> Leigh, Thanks for the quick and thorough reply, I have responded inline. Thanks, Steve Speicher "Klotz, Leigh" <Leigh.Klotz@xerox.com> wrote on 03/28/2007 01:49:42 PM: > Steve, > We discussed this issue at today's teleconference and have some > observations and questions. > We believe that xsi:type cannot be used to contradict an > xf:model/@schema or xf:model/xsd:schema declaration, only to refine it > under rules specified normatively by XML Schema. > If you agree with this statement but think our wording conveys > otherwise, please read point 1. > If you believe that XForms can or should allow xsi:type to contradict an > author-specified schema, please read points 2, 3, and 4. > 1. We agree with you in general that "the wording is intended to state > that the node is valid if it passes valdation for both 1) External or > inline schema as possibly redefined by xsi:type 2) type MIP." However, > we don't agree that about "redefined." There is no attempt to give > special meaning to xsi:type outside its definition in XML Schema. All > use of xsi:type in instances is bound by XML Schema processing rules, > and is normatively defined there, not in XForms. (But see point 4). > Instead of > "the node satisfies all applicable XML schema definitions (including > those associated by the type model item property, by an external or > an inline schema, *or* by xsi:type)" > Do you think it means the following? > "the node satisfies all applicable XML schema definitions (including > those associated by the type model item property, by an external or > an inline schema, *and* by xsi:type)" > If so, we hope that instead of re-issuing the erratum, you are satisfied > with our assertion here that it is XML Schema that normatively defines > xsi:type, not XForms. I am satisfied that XForms is not attempting to give special meaning to xsi:type. Perhaps this can be clarified in 1.1 drafts? > 2. We do not understand the reference to "widely deployed usages of > validated XML Instances."XML Schema defines xsi:type for the > substutition, restriction, or > extension of existing types. > A document that attempts to override the type of an element with an > unrelated type is not valid. > According to XML Schema, only with a type defined by restriction or > extension, and in some cases by substitution. > Please see http://www.w3.org/TR/xmlschema-1/#cos-ct-derived-ok > To test this point, I've taken your example below and defined schema.xsd > which I think describes the case. > It defines a type for the child element which contains only other child > elements, and a type called "newType" that contains grandChild elements, > which themselves are xsd:string. > Here is the Schema: ..snip > When I attempt to validate the stuff.xml document with a Schema > processor I get this error: > Element '{http://sample.com}child', attribute > '{http://www.w3.org/2001/XMLSchema-instance}type': The type definition > '{http://sample.com}newType', specified by > xsi:type, is blocked or not validly derived from the type definition of > the element declaration. > Element '{http://sample.com}grandchild': This element is not expected. > Expected is ( {http://sample.com}child ). > stuff.xml fails to validate > Do you know of a situation in which a Schema processor would allow > xsi:type to declare a type for an element which is in conflict with the > Schema type definition? Only as you said by extension or restriction, which still can allow you to have instances that can't validate to be types. Take this schema for an example: <?xml version="1.0"?> <xsd:schema targetNamespace="http://sample.com" xmlns:s="http://sample.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:element name="root"> <xsd:complexType> <xsd:sequence minOccurs="1" maxOccurs="1"> <xsd:element name="child" type="s:childType" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:complexType name="childType"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="grandChild" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="newType"> <xsd:complexContent> <xsd:restriction base="s:childType"> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element name="grandChild" type="xsd:date" /> </xsd:sequence> </xsd:restriction> </xsd:complexContent> </xsd:complexType> </xsd:schema> Then validating this instance: <?xml version="1.0" encoding="UTF-8"?> <root xmlns="http://sample.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://sample.com schema.xsd"> <child xsi:type="newType"> <grandChild>Stuff</grandChild> </child> </root> shows that the value "Stuff" is not a valid xsd:date, for example > 3. Standalone Xerces > By Standalone Xerces, do you mean that processing the stuff.xml file > without access to the ssample.xsd schema file validates? > Given that there is no Schema information available, and there is no > type definition for xsi:type either, I believe that the best Xerces can > do is declare that the document is well-formed, and cannot test its > validity. Do you disagree with this? What I meant by "standalone", was validation done outside of an XForms processor. In the XML instance example I gave, it clearly indicated using xsi:schemaLocation which schema to validate against. It should have access to the schema.xsd schema from a standalone validator, or at least an editing environment that supports XML validation. > 4. In Schema validation, it is user of the document who gets to decide > what Schema to use, not the document itself. > To do otherwise would negate the value of Schema validation, as > nefarious instance data could circumvent its own validation! > For this reason, Schema processors are allowed to ignore > xsi:schemaLocation attributes in documents. > See http://www.w3.org/TR/xmlschema-1/#schema-loc which states > Unless directed otherwise, for example by the invoking application or > by command line option, ... > In XForms, we take the xf:model/@schema attribute and the xsd:schema > child elements of xf:model to be direction from the invoking > application. > By #1 above, the xsi:type attribute in the instance cannot specify > anything in conflict with the Schema specified by the form author, so we > conclude that the correct behavior is to fail to submit because the > document is not valid. > So if I understand what you are saying, these 2 statements are not equal: 1) <xf:model schema="schema.xsd"> <xf:instance> <t:root>...</t:root> </xf:instance> </xf:model> 2) <xf:model> <xf:instance> <t:root xsi:schemaLocation="http://sample.com schema.xsd">...</root> </xf:instance> </xf:model> Since as the author of #1 indicates the overriding schema to use for validation and author of content of #2 indicates what schema to use for validating separate instance. Also XForms processors can not take the schema in #2 and treat as the @schema attribute on <xf:model>, as has to process any xsi:type[s]. > Leigh.-----Original Message----- > From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On > Behalf Of Steve K Speicher > Sent: Monday, March 26, 2007 3:42 PM > To: www-forms@w3.org > Subject: Re: 1.0 errata section 10 (complex type validation > clarification) > See thread > http://lists.w3.org/Archives/Public/www-forms/2006Aug/0047.html > and resulting errata > http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E10a > I find that the definition for validation in the errata is too strict > anddoesn't match that of some widely deployed usages of validated XML > instances. > Take for instance this example: > <!-- simple sample XForms model --> > <xf:model schema="schema.xsd"> > <xf:instance src="stuff.xml" /> > </xf:model> > <!-- stuff.xml --> > <root xmlns="http://sample.com" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://sample.com schema.xsd"> > <child xsi:type="newType"> > <grandchild>Stuff</grandchild> > </child> > </root> > According to the errata it says: "the node satisfies all applicable > XML schema definitions (includingthose associated by the type model item > property, by an external or aninline schema, or by xsi:type)" > If for example, my "newType" defines a conflicting complex content model > for <child> then there is no way for my instance to validate, therefore > itcan never be submitted. If you validate the instance using a > standalone > validator such as Xerces, it validates fine. > I believe the wording is intended to state that the node is valid if it > passes validation for both these: > 1) external or inline schema, as possibly redefined by xsi:type > 2) type MIP > The errata wording seems to indicate that both external/inline schema > andxsi:type schema type definitions should be used.Regards, > Steve Speicher
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Steve, please see comments inline. > Leigh, > > Thanks for the quick and thorough reply, I have responded inline. > > Thanks, > Steve Speicher > > "Klotz, Leigh" <Leigh.Klotz@xerox.com> wrote on 03/28/2007 01:49:42 PM: > >> Steve, >> We discussed this issue at today's teleconference and have some >> observations and questions. >> We believe that xsi:type cannot be used to contradict an >> xf:model/@schema or xf:model/xsd:schema declaration, only to refine it >> under rules specified normatively by XML Schema. >> If you agree with this statement but think our wording conveys >> otherwise, please read point 1. >> If you believe that XForms can or should allow xsi:type to contradict an >> author-specified schema, please read points 2, 3, and 4. >> 1. We agree with you in general that "the wording is intended to state >> that the node is valid if it passes valdation for both 1) External or >> inline schema as possibly redefined by xsi:type 2) type MIP." However, >> we don't agree that about "redefined." There is no attempt to give >> special meaning to xsi:type outside its definition in XML Schema. All >> use of xsi:type in instances is bound by XML Schema processing rules, >> and is normatively defined there, not in XForms. (But see point 4). >> Instead of >> "the node satisfies all applicable XML schema definitions (including >> those associated by the type model item property, by an external or >> an inline schema, *or* by xsi:type)" >> Do you think it means the following? >> "the node satisfies all applicable XML schema definitions (including >> those associated by the type model item property, by an external or >> an inline schema, *and* by xsi:type)" >> If so, we hope that instead of re-issuing the erratum, you are satisfied >> with our assertion here that it is XML Schema that normatively defines >> xsi:type, not XForms. > > I am satisfied that XForms is not attempting to give special meaning to > xsi:type. Perhaps this can be clarified in 1.1 drafts? > We clarified it, see http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#model-using-atomic for changes. >> 2. We do not understand the reference to "widely deployed usages of >> validated XML Instances."XML Schema defines xsi:type for the >> substutition, restriction, or >> extension of existing types. >> A document that attempts to override the type of an element with an >> unrelated type is not valid. >> According to XML Schema, only with a type defined by restriction or >> extension, and in some cases by substitution. >> Please see http://www.w3.org/TR/xmlschema-1/#cos-ct-derived-ok >> To test this point, I've taken your example below and defined schema.xsd >> which I think describes the case. >> It defines a type for the child element which contains only other child >> elements, and a type called "newType" that contains grandChild elements, >> which themselves are xsd:string. >> Here is the Schema: > ..snip >> When I attempt to validate the stuff.xml document with a Schema >> processor I get this error: >> Element '{http://sample.com}child', attribute >> '{http://www.w3.org/2001/XMLSchema-instance}type': The type definition >> '{http://sample.com}newType', specified by >> xsi:type, is blocked or not validly derived from the type definition of >> the element declaration. >> Element '{http://sample.com}grandchild': This element is not expected. >> Expected is ( {http://sample.com}child ). >> stuff.xml fails to validate >> Do you know of a situation in which a Schema processor would allow >> xsi:type to declare a type for an element which is in conflict with the >> Schema type definition? > > Only as you said by extension or restriction, which still can allow you to > have instances that can't validate to be types. > > Take this schema for an example: > > <?xml version="1.0"?> > <xsd:schema targetNamespace="http://sample.com" > xmlns:s="http://sample.com" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified"> > <xsd:element name="root"> > <xsd:complexType> > <xsd:sequence minOccurs="1" maxOccurs="1"> > <xsd:element name="child" > type="s:childType" /> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > > <xsd:complexType name="childType"> > <xsd:sequence minOccurs="0" maxOccurs="unbounded"> > <xsd:element name="grandChild" type="xsd:string" > /> > </xsd:sequence> > </xsd:complexType> > > <xsd:complexType name="newType"> > <xsd:complexContent> > <xsd:restriction base="s:childType"> > <xsd:sequence minOccurs="0" > maxOccurs="unbounded"> > <xsd:element name="grandChild" > type="xsd:date" /> > </xsd:sequence> > </xsd:restriction> > </xsd:complexContent> > </xsd:complexType> > </xsd:schema> > > Then validating this instance: > > <?xml version="1.0" encoding="UTF-8"?> > <root xmlns="http://sample.com" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://sample.com schema.xsd"> > <child xsi:type="newType"> > <grandChild>Stuff</grandChild> > </child> > </root> > > shows that the value "Stuff" is not a valid xsd:date, for example > Yes, we agree. >> 3. Standalone Xerces >> By Standalone Xerces, do you mean that processing the stuff.xml file >> without access to the ssample.xsd schema file validates? >> Given that there is no Schema information available, and there is no >> type definition for xsi:type either, I believe that the best Xerces can >> do is declare that the document is well-formed, and cannot test its >> validity. Do you disagree with this? > > What I meant by "standalone", was validation done outside of an XForms > processor. > In the XML instance example I gave, it clearly indicated using > xsi:schemaLocation which schema to validate against. It should have > access to the schema.xsd schema from a standalone validator, or at least > an editing environment that supports XML validation. > We agree. If you're using an instance outside XForms you can turn on Schema validation by using xsi:schemaLocation. Note that this is only a hint to the Schema processor, it is allowed to ignore the hint (see http://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation for reference). >> 4. In Schema validation, it is user of the document who gets to decide >> what Schema to use, not the document itself. >> To do otherwise would negate the value of Schema validation, as >> nefarious instance data could circumvent its own validation! >> For this reason, Schema processors are allowed to ignore >> xsi:schemaLocation attributes in documents. >> See http://www.w3.org/TR/xmlschema-1/#schema-loc which states >> Unless directed otherwise, for example by the invoking application or >> by command line option, ... >> In XForms, we take the xf:model/@schema attribute and the xsd:schema >> child elements of xf:model to be direction from the invoking >> application. >> By #1 above, the xsi:type attribute in the instance cannot specify >> anything in conflict with the Schema specified by the form author, so we >> conclude that the correct behavior is to fail to submit because the >> document is not valid. >> > > So if I understand what you are saying, these 2 statements are not equal: > > 1) > <xf:model schema="schema.xsd"> > <xf:instance> > <t:root>...</t:root> > </xf:instance> > </xf:model> > > 2) > <xf:model> > <xf:instance> > <t:root xsi:schemaLocation="http://sample.com schema.xsd">...</root> > </xf:instance> > </xf:model> > > Since as the author of #1 indicates the overriding schema to use for > validation and > author of content of #2 indicates what schema to use for validating > separate instance. > Also XForms processors can not take the schema in #2 and treat as the > @schema attribute on <xf:model>, as > has to process any xsi:type[s]. > Yes, you are right. XForms processors ignore any xsi:schemaLocation hints. So it's the responsibility of the form author to provide a schema attribute on element xf:model in order to process xsi:type attributes in terms of validation. Regards, Ulrich Nicolas Lissé. For the Forms WG >> Leigh.-----Original Message----- >> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On >> Behalf Of Steve K Speicher >> Sent: Monday, March 26, 2007 3:42 PM >> To: www-forms@w3.org >> Subject: Re: 1.0 errata section 10 (complex type validation >> clarification) >> See thread >> http://lists.w3.org/Archives/Public/www-forms/2006Aug/0047.html >> and resulting errata >> http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E10a >> I find that the definition for validation in the errata is too strict >> anddoesn't match that of some widely deployed usages of validated XML >> instances. >> Take for instance this example: >> <!-- simple sample XForms model --> >> <xf:model schema="schema.xsd"> >> <xf:instance src="stuff.xml" /> >> </xf:model> >> <!-- stuff.xml --> >> <root xmlns="http://sample.com" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://sample.com schema.xsd"> >> <child xsi:type="newType"> >> <grandchild>Stuff</grandchild> >> </child> >> </root> >> According to the errata it says: "the node satisfies all applicable >> XML schema definitions (includingthose associated by the type model item >> property, by an external or aninline schema, or by xsi:type)" >> If for example, my "newType" defines a conflicting complex content model >> for <child> then there is no way for my instance to validate, therefore >> itcan never be submitted. If you validate the instance using a >> standalone >> validator such as Xerces, it validates fine. >> I believe the wording is intended to state that the node is valid if it >> passes validation for both these: >> 1) external or inline schema, as possibly redefined by xsi:type >> 2) type MIP >> The errata wording seems to indicate that both external/inline schema >> andxsi:type schema type definitions should be used.Regards, >> Steve Speicher
PROBLEM ID: 92
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
We clarified in the spec that nillable is not applicable to the type MIP because schema associates it with element validity, not type validity.
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, I am sending this following an interesting comment about schema types from a user. XForms 1.1 specifies that: "The type model item property associates a datatype (as defined in [XML Schema part 2]) with the string-value (as defined in [XPath 1.0]) of an instance node. The datatype being associated can be obtained from a simpleType definition or a simpleContent definition from a complexType. If the datatype cannot be obtained as just described, then the Default Value of xsd:string is used." Now, I assume that this means I can write something like this: <xs:element name="state-element"> <xs:complexType> <xs:simpleContent> <xs:extension base="test:state-type"> <xs:attribute name="code" type="xs:integer"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> use it as follows: <xforms:bind nodeset="state" type="test:state-element"/> and I should expect the validator to validate the content of my <state> instance element using the datatype part of my xs:element definition. First, is this correct? Second, what if my type is as follows instead: <xs:element name="state-element" nillable="true"> <xs:complexType> <xs:simpleContent> <xs:extension base="test:state-type"> <xs:attribute name="code" type="xs:integer"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> and my instance element: <state xsi:nil="true">CA</state> Is XForms supposed to honor xsi:nil in this case, and accept an empty content for <state>? My guess is that it is not in fact part of the dataype. XML Schema says: "If {nillable} is true, then an element may also be ·valid· if it carries the namespace qualified attribute with [local name] nil from namespace http://www.w3.org/2001/XMLSchema-instance and value true (see xsi:nil (§2.6.2)) even if it has no text or element content despite a {content type} which would otherwise require content." So the nil thing seems to apply to the validity of the element, not of its datatype part. However, after all the form author is binding a nillable element type to an XForms instance element, and it is not very intuitive that xsi:nil won't work in this case. Whatever the answer, I think that it would be very valuable to clarify this in the spec. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, This is a very technically interesting issue you have raised. The working group agrees that nillable appears to be a statement about the content of an element. However, our hands are a bit tied here because XML Schema Part 1 Section 3.3.4 associates the notion of nillable with "Element Locally Valid (Element)" and not "Element Locally Valid (Type)". By comparison, XForms associates the type MIP with the type validation, and more specifically with the simple content part of a schema type. Hence, we agree with your assessment that a type MIP assignment does not associate nillable with a node. Moreover, a clarification note in the specification does not appear to be necessary because a type MIP also *cannot* refer to an element declaration, which is the only place where nillable can occur in an XML schema. Because nillable is associated with element validity and not type validity, it cannot be attached to a schema type declaration. If your schema below were modified to include a named complexType for "state-element", it would be clearer that the nillable attribute is attached to the xs:element that declares "state-element" and not the complexType for "state-element". However, this modification is necessary in order for you to have a correct XForm, as the type MIP must refer to the complexType for "state-element" and not the element declaration itself. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > All, > > I am sending this following an interesting comment about schema types > from a user. > > XForms 1.1 specifies that: > > "The type model item property associates a datatype (as defined in > [XML Schema part 2]) with the string-value (as defined in [XPath > 1.0]) of an instance node. The datatype being associated can be > obtained from a simpleType definition or a simpleContent definition > from a complexType. If the datatype cannot be obtained as just > described, then the Default Value of xsd:string is used." > > Now, I assume that this means I can write something like this: > > <xs:element name="state-element"> > <xs:complexType> > <xs:simpleContent> > <xs:extension base="test:state-type"> > <xs:attribute name="code" type="xs:integer"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:element> > > use it as follows: > > <xforms:bind nodeset="state" type="test:state-element"/> > > and I should expect the validator to validate the content of my > <state> instance element using the datatype part of my xs:element > definition. > > First, is this correct? > > Second, what if my type is as follows instead: > > <xs:element name="state-element" nillable="true"> > <xs:complexType> > <xs:simpleContent> > <xs:extension base="test:state-type"> > <xs:attribute name="code" type="xs:integer"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:element> > > and my instance element: > > <state xsi:nil="true">CA</state> > > Is XForms supposed to honor xsi:nil in this case, and accept an empty > content for <state>? > > My guess is that it is not in fact part of the dataype. XML Schema says: > > "If {nillable} is true, then an element may also be ?valid? if it > carries the namespace qualified attribute with [local name] nil > from namespace http://www.w3.org/2001/XMLSchema-instance and value > true (see xsi:nil (?2.6.2)) even if it has no text or element > content despite a {content type} which would otherwise require > content." > > So the nil thing seems to apply to the validity of the element, not of > its datatype part. > > However, after all the form author is binding a nillable element type > to an XForms instance element, and it is not very intuitive that > xsi:nil won't work in this case. > > Whatever the answer, I think that it would be very valuable to clarify > this in the spec. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 97
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#email-type Please add to the "Examples of invalid xforms:email addresses" mailto:editors@example.com (and point out, maybe, that this is a valid anyURI) Steven
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, These have been done and can now be found in the editor's draft available from the working group home pages. Best regards, John Boyer > > > http://www.w3.org/TR/xforms11/#email-type > > Please add to the "Examples of invalid xforms:email addresses" > > mailto:editors@example.com > > (and point out, maybe, that this is a valid anyURI) > > Steven > >
PROBLEM ID: 22
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Gary F Stevens" <gfsteven@us.ibm.com> ------------ha3xB2oVlVbZrkN7gai8Pf Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit ----- Forwarded by Gary F Stevens/Raleigh/IBM on 04/13/2007 12:06 PM ----- Gary F Stevens/Raleigh/I BM To www-forms@w3.org 04/12/2007 01:38 cc PM Subject Confusion on datatypes with empty content Hello, While reading through the XForms 1.1 specification I became confused by the language describing datatypes which allow empty content in section 5.2.7. The second paragraph of the description seems to contradict the first paragraph. While the first paragraph says "The following XForms datatypes are defined to allow either empty content or the content allowed by the corresponding XML schema datatype" the second paragraph says "The indicated XForms datatypes do not allow empty string content and some others already accepted empty string data". Gary F Stevens Software Group - Emerging Standards IBM/US/Raleigh-RTP ------------ha3xB2oVlVbZrkN7gai8Pf Content-Disposition: attachment; filename=ecblank.gif Content-Type: image/gif; name=ecblank.gif Content-Transfer-Encoding: Base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------------ha3xB2oVlVbZrkN7gai8Pf Content-Disposition: attachment; filename=attachment955.htm Content-Type: text/html; name=attachment955.htm Content-Transfer-Encoding: Quoted-Printable <html><body> <p><font size=3D"2" color=3D"#800080">----- Forwarded by Gary F Stevens/= Raleigh/IBM</font><font size=3D"2" color=3D"#800080"> on 04/13/2007 12:0= 6 PM</font><font size=3D"2" color=3D"#800080"> -----</font><br> <br> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td style=3D"background-image:url(cid:1__=3D08BBF82FD= FCBE6E08f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width=3D= "40%"> <ul> <ul> <ul> <ul><b><font size=3D"2">Gary F Stevens/Raleigh/IBM</font></b><font size=3D= "2"> </font> <p><font size=3D"2">04/12/2007 01:38 PM</font></ul> </ul> </ul> </ul> </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"1= 00%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E08f9e= 8a93df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">www-forms@w3.org</font></td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"1= 00%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E08f9e= 8a93df938@us.ibm.com" border=3D"0" alt=3D""><br> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""><br> <div align=3D"right"><font size=3D"2">Subject</font></div></td><td width= =3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D08BBF82FDFCBE6E= 08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""><br> <font size=3D"2">Confusion on datatypes with empty content</font></td></= tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:2__=3D08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:2__=3D= 08BBF82FDFCBE6E08f9e8a93df938@us.ibm.com" border=3D"0" alt=3D""></td></t= r> </table> </td></tr> </table> Hello,<br> <br> While reading through the XForms 1.1 specification I became confused by = the language describing datatypes which allow empty content in section 5= .2.7. The second paragraph of the description seems to contradict the fi= rst paragraph. While the first paragraph says "The following XForm= s datatypes are defined to allow either empty content or the content all= owed by the corresponding XML schema datatype" the second paragraph= says "The indicated XForms datatypes do not allow empty string con= tent and some others already accepted empty string data".<br> <br> Gary F Stevens<br> Software Group - Emerging Standards<br> IBM/US/Raleigh-RTP</body></html> ------------ha3xB2oVlVbZrkN7gai8Pf--
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> Many thanks for this comment. We agree that it was confusing. We have reworded this to make it clear that all the datatypes allow empty. Best wishes, Steven Pemberton For the Forms WG > While reading through the XForms 1.1 specification I became confused by the > language describing datatypes which allow empty content in section 5.2.7. > The second paragraph of the description seems to contradict the first > paragraph. While the first paragraph says "The following XForms datatypes > are defined to allow either empty content or the content allowed by the > corresponding XML schema datatype" the second paragraph says "The indicated > XForms datatypes do not allow empty string content and some others already > accepted empty string data".
PROBLEM ID: 62
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#datatypes-xforms Since these are all in the XForms namespace, then the prefix is presumably optional, so I can write the following with impunity: <bind nodeset="size" type="integer" /> Hooray! Please point this out.
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven Many thanks for this comment. We have changed the spec accordingly. Best wishes, Nick Van den Bleeken For the Forms WG > > http://www.w3.org/TR/xforms11/#datatypes-xforms > > Since these are all in the XForms namespace, then the prefix is > presumably optional, so I can write the following with impunity: > > <bind nodeset="size" type="integer" /> > > Hooray! Please point this out. > > >
PROBLEM ID: 21
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> Three issues regarding Section 9.3.5 and 9.3.6 (and technically 9.3.1): 1) When insert or delete actions occur, the repeat index is updated for any repeat bound to node(s) inserted or deleted. Currently, this is described in the insert and delete actions, which is inappropriate since it is a property of repeats. The intent of insert and delete in XForms 1.1 is to be generalized data manipulators, so they should not contain language about manipulating repeat indices. Moreover, now that we have the proper context information in xforms-insert and xforms-delete it is even possible to describe how repeat index manipulation could be achieved by having repeat semantics imply listeners for xforms-insert and xforms-delete with index update according to whether the nodes listed are applicable to the given repeat. Although this is an implementation, I think it is important to preserve the property that the repeat indices are updated immediately (as is the case now) and not at some later time that might seem more obvious, such as xforms-refresh. 2) It is completely unacceptable to me that the index of a nested repeat is reset when its containing repeat's index is updated. This behavior should simply be stricken from XForms 1.1 as there is no earthly reason for doing it. I believe it was added to XForms 1.0 at a time when repeating was not nearly as well understood as it is now. I believe there was the thought that there would only exist one instance of a data structure to represent any repeat, including an inner repeat, Hence the index of that object would be changed to the start value in a newly inserted repeat item (9.3.5, bullet 8). I believe similar reasoning was used to arrive at inner repeat reinitialization in the delete case (9.3.6 bullet 5). However, we now know that inner repeats are similar to inner switches in an outer repeat. Just as the selected case of a switch may be different in each repeat item, the index of an inner repeat may be different in each repeat item. Hence there is no need to modify the indexes of inner repeats when a repeat item in the outer repeat is created or destroyed, just as there is no need to reset the cases of all switches in all repeat items just because one is added or deleted. Alternately, observe that if the inner repeat index adjustment really were necessary on insert and delete, then there would be a flaw in that case adjustment of repeated switches would also be needed, and the spec makes no allowance for this. The proposed solution is that XForms should retain only the simpler behavior which says that a repeat index is updated if the context node of the indexed repeat item is deleted or if a new node is inserted into the 3) Insert and Delete are now in the wrong section. In XForms 1.1, insert and delete have become generalized data manipulators. They are not really tied to repeat anymore in that we do suggest their use in other cases, like extracting the data payload from a SOAP envelope. To avoid confusion that insert/delete should only be used with repeated data, they should be moved to Section 10. This of course is another good argument for moving the index updating logic to repeat in 9.3.1. John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> The working group accepted this LC comment, and further requested in the resulting action item (Action 2007-08-15.3) that the content of http://lists.w3.org/Archives/Public/public-forms/2007Aug/0038.html should be accounted for. The solution has been implemented and now appears in the editor's draft available from the working group homepage. See in particular sections 9.3.3 and 9.3.4 of the specification for language about repeat index management during repeat processing and user interaction, and note that the insert and delete actions have been moved to Section 10 and stripped of language pertaining to repeat index management (except for notes referring the reader back to Section 9.3.3). John Boyer > Three issues regarding Section 9.3.5 and 9.3.6 (and technically 9.3.1): > > 1) When insert or delete actions occur, the repeat index is updated for > any repeat bound to node(s) inserted or deleted. > > Currently, this is described in the insert and delete actions, which is > inappropriate since it is a property of repeats. The intent of insert and > delete in XForms 1.1 is to be generalized data manipulators, so they > should not contain language about manipulating repeat indices. > > Moreover, now that we have the proper context information in xforms-insert > and xforms-delete it is even possible to describe how repeat index > manipulation could be achieved by having repeat semantics imply listeners > for xforms-insert and xforms-delete with index update according to whether > the nodes listed are applicable to the given repeat. > > Although this is an implementation, I think it is important to preserve > the property that the repeat indices are updated immediately (as is the > case now) and not at some later time that might seem more obvious, such as > xforms-refresh. > > > 2) It is completely unacceptable to me that the index of a nested repeat > is reset when its containing repeat's index is updated. This behavior > should simply be stricken from XForms 1.1 as there is no earthly reason > for doing it. > > I believe it was added to XForms 1.0 at a time when repeating was not > nearly as well understood as it is now. I believe there was the thought > that there would only exist one instance of a data structure to represent > any repeat, including an inner repeat, Hence the index of that object > would be changed to the start value in a newly inserted repeat item > (9.3.5, bullet 8). I believe similar reasoning was used to arrive at > inner repeat reinitialization in the delete case (9.3.6 bullet 5). > > However, we now know that inner repeats are similar to inner switches in > an outer repeat. Just as the selected case of a switch may be different > in each repeat item, the index of an inner repeat may be different in each > repeat item. Hence there is no need to modify the indexes of inner > repeats when a repeat item in the outer repeat is created or destroyed, > just as there is no need to reset the cases of all switches in all repeat > items just because one is added or deleted. > > Alternately, observe that if the inner repeat index adjustment really were > necessary on insert and delete, then there would be a flaw in that case > adjustment of repeated switches would also be needed, and the spec makes > no allowance for this. > > The proposed solution is that XForms should retain only the simpler > behavior which says that a repeat index is updated if the context node of > the indexed repeat item is deleted or if a new node is inserted into the > > > 3) Insert and Delete are now in the wrong section. > > In XForms 1.1, insert and delete have become generalized data > manipulators. They are not really tied to repeat anymore in that we do > suggest their use in other cases, like extracting the data payload from a > SOAP envelope. To avoid confusion that insert/delete should only be used > with repeated data, they should be moved to Section 10. > > This of course is another good argument for moving the index updating > logic to repeat in 9.3.1. > > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 3
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Joern Turner" <joern.turner@dreamlab.net> During February 28, 2007 telecon the usefulness of the notion of a homogeneous collection was discussed. Members agreed to remove this notion from XForms 1.1 WD completely cause: - it's confusing to users - the definition of continuity of elements is weak as John pointed out (existence of text nodes in between elements) - it is not considered a performance issue by implementors - it constrains form authors in certain use cases
FOLLOWUP 1:
From: www-forms-editor-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- > During February 28, 2007 telecon the usefulness of the notion of a > homogeneous collection was discussed. Members agreed to remove this > notion from XForms 1.1 WD completely cause: > > - it's confusing to users > - the definition of continuity of elements is weak as John pointed out > (existence of text nodes in between elements) > - it is not considered a performance issue by implementors > - it constrains form authors in certain use cases Joern, Thanks for your comment. At the Forms WG meeting today the WG agreed with your suggestion, and will adopt it. Many thanks. Steven Pemberton For the Forms WG
REPLY 1:
From: Steven Pemberton <xforms-issues@mn.aptest.com> > During February 28, 2007 telecon the usefulness of the notion of a > homogeneous collection was discussed. Members agreed to remove this > notion from XForms 1.1 WD completely cause: > > - it's confusing to users > - the definition of continuity of elements is weak as John pointed out > (existence of text nodes in between elements) > - it is not considered a performance issue by implementors > - it constrains form authors in certain use cases Joern, Thanks for your comment. At the Forms WG meeting today the WG agreed with your suggestion, and will adopt it. Many thanks. Steven Pemberton For the Forms WG
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> The working group agreed to the removal of the paragraph. > The following paragraph in section 9.3.8 should be removed: > > The binding expression attached to the repeating sequence returns a > node-set of the collection being populated, not an individual node. Within > the body of element repeat, binding expressions are evaluated with a > context node of the node determined by the index. Repeat processing uses > XPath expressions to address the collection over which element repeat > operates. > > The first and third sentences are obvious given other material in Section > 9, and the second sentence is old and wrong, contradicting the copious > material in Section 7.4 on evaluation context (see esp. point 2c and 2d in > 7.4). > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
REPLY 3:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Aaron, Spec ready solutions are now available for both of these issues in the editor's draft. [1] (9.3.3 Repeat Processing and 9.3.6 The itemset Element) 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. Regards, Nick Van den Bleeken [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-module > Full_Name: Aaron Reed > Submission from: (NULL) (32.97.110.142) > Submitted by: boyerj > > > 35) Section 9.3.2 - how should we handle XML event handlers contained at > root level under a repeat or a non-xforms element with repeat attrs? Like > itemset (listeners registered on the repeat rows and not on the repeat > itself)? > > 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions > contained by an itemset to handle events on the itemset." It seems odd > that an XForms action OUTSIDE the itemset can handle events on the itemset. > And non-XForms actions in the itemset won't be repeated under the anonymous > items. For example, the xhtml or xml events 'handler' element would be > nice to have repeated to allow the form author to handle xforms-select and > xforms-deselect events with script. > >
PROBLEM ID: 24
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> I seem to recall some years-old discussions about the effect of a repeat index change on the XForms processor. I seem to recall a face to face discussion in which it was suggested that a repeat index change should correspond to an automatic rebuild because bind nodesets or MIP expressions may contain invocations of the index() function. I also recall the conversation indicating that implementations could do something more optimized that a full rebuild, such as focusing on binds that actually invoke index() on the affected repeat since those that don't would be unaffected. However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8) that changing the focus to a control in a repeat item (row) other than the indexed repeat item does cause the repeat index to implicitly change. In combination with the statement above, this would mean an implicit rebuild-recalculate-revalidate-refresh based. Moreover, changing focus may change the index of multiple repeats that are nested, so one's spidey sense gets the tingle of another optimization. But the problem is that I cannot find any language in the XForms spec that even implies a connection between repeat index changes and automatic rebuilding. For the record, I think the connection between repeat index and rebuild is wrong, and I was going to write a last call comment to suggest its removal. But alas I have been foiled by the fact that it already doesn't seem to exist in the spec. If someone can find this, please let me know; otherwise I will proceed on the assumption that the spec does not follow a repeat index change with an automatic rebuild. I believe that the original discussion about automatically rebuilding on index change was held, at least in part, from a desire to correct for the fact that index() *could be* invoked from the XPaths within an XForms bind (i.e. from model binding expressions). However, since such automatic rebuild is ultimately doomed to failure (because of automatic index changes on focus change in 9.3.8), it seems better to consider restricting the index() function to only being used in certain cases. Clearly, the index() function was designed for use in the XPaths of XForms actions. When index() is used in a UI binding, it is possible though somewhat difficult to create problems due to the staleness of the result. More significant problems are easier to produce when index() is used in a model binding expression. In the past, this would have been hard, but XForms now requires different exception behavior based on where an XPath is located. For example, in Section 7.1, the choice of a binding exception versus a compute exception is based on where the XPath is located. An invocation of index() appearing in any XPath other than those used in XForms actions should either produce NaN or preferrably an appropriate exception. John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi John, We acknowledge the problem, but we have decided to defer this to a future version. Regards, Nick Van den Bleeken > I seem to recall some years-old discussions about the effect of a repeat > index change on the XForms processor. > > I seem to recall a face to face discussion in which it was suggested that > a repeat index change should correspond to an automatic rebuild because > bind nodesets or MIP expressions may contain invocations of the index() > function. I also recall the conversation indicating that implementations > could do something more optimized that a full rebuild, such as focusing on > binds that actually invoke index() on the affected repeat since those that > don't would be unaffected. > > However, note that XForms 1.0 SE and XForms 1.1 both now say (in 9.3.8) > that changing the focus to a control in a repeat item (row) other than the > indexed repeat item does cause the repeat index to implicitly change. In > combination with the statement above, this would mean an implicit > rebuild-recalculate-revalidate-refresh based. Moreover, changing focus > may change the index of multiple repeats that are nested, so one's spidey > sense gets the tingle of another optimization. > > But the problem is that I cannot find any language in the XForms spec that > even implies a connection between repeat index changes and automatic > rebuilding. For the record, I think the connection between repeat index > and rebuild is wrong, and I was going to write a last call comment to > suggest its removal. But alas I have been foiled by the fact that it > already doesn't seem to exist in the spec. If someone can find this, > please let me know; otherwise I will proceed on the assumption that the > spec does not follow a repeat index change with an automatic rebuild. > > I believe that the original discussion about automatically rebuilding on > index change was held, at least in part, from a desire to correct for the > fact that index() *could be* invoked from the XPaths within an XForms bind > (i.e. from model binding expressions). > > However, since such automatic rebuild is ultimately doomed to failure > (because of automatic index changes on focus change in 9.3.8), it seems > better to consider restricting the index() function to only being used in > certain cases. Clearly, the index() function was designed for use in the > XPaths of XForms actions. When index() is used in a UI binding, it is > possible though somewhat difficult to create problems due to the staleness > of the result. More significant problems are easier to produce when > index() is used in a model binding expression. > > In the past, this would have been hard, but XForms now requires different > exception behavior based on where an XPath is located. For example, in > Section 7.1, the choice of a binding exception versus a compute exception > is based on where the XPath is located. An invocation of index() > appearing in any XPath other than those used in XForms actions should > either produce NaN or preferrably an appropriate exception. > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 118
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
Some of the issues were mistakes on Aaron's part; others resulted in fixes.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 31) Section 9.2.2 - no mention of the possible "value" attribute or its potential behavior as a child toggle. Should at least be a nod to it. 32) Section 9.2.3.1 - no schema change to show that @value is a possible attribute of case element. 33) Section 9.3.1 - "if an element of the collection is non-relevant..." The 'if' starts the sentence but isn't capitalized. 34) Section 9.3.1 - homogeneous collection example - the delete action should be handling a DOMActivate event, not an 'activate' event. 35) Section 9.3.2 - how should we handle XML event handlers contained at root level under a repeat or a non-xforms element with repeat attrs? Like itemset (listeners registered on the repeat rows and not on the repeat itself)? 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions contained by an itemset to handle events on the itemset." It seems odd that an XForms action OUTSIDE the itemset can handle events on the itemset. And non-XForms actions in the itemset won't be repeated under the anonymous items. For example, the xhtml or xml events 'handler' element would be nice to have repeated to allow the form author to handle xforms-select and xforms-deselect events with script. 37) Section 9.3.5 - if we are inserting attributes, why does the order matter? I didn't think that attribute order was guaranteed to be honored in DOM. 38) Section 9.3.5 - the example with the repeat - there needs to be @id="R" on the repeat or the example won't work since the xf:insert uses the index() XPath extension function. 39) Section 9.3.7 - "if the index evaluates to NaN the action has no effect." The 'if' starts the sentence but isn't capitalized.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, This is a response to several issues you raised in your last call comment email dated April 30. Two of the issues in the sequence 31-39 have been flagged as separate issues, but I listed them below so you would know they weren't skippped accidentally. Please let us know if you have any further concerns about the other issues that are addressed below. You can see the results of the fixes in the editor's copy of the spec available from the Forms WG website. Thanks, John Boyer 31) Section 9.2.2 - no mention of the possible "value" attribute or its potential behavior as a child toggle. Should at least be a nod to it. Yes. This is because the case element child of switch (defined in 9.2.2) does not have a value attribute. Section 9.2.3.1 defines the case element child of toggle, which is a completely separate element. It has the same tag name, but a different parent. That is the case element that supports the value attribute (and not the selected attribute). 32) Section 9.2.3.1 - no schema change to show that @value is a possible attribute of case element. The schema will be changed. 33) Section 9.3.1 - "if an element of the collection is non-relevant..." The 'if' starts the sentence but isn't capitalized. Fixed. Not diff-marked. 34) Section 9.3.1 - homogeneous collection example - the delete action should be handling a DOMActivate event, not an 'activate' event. Fixed, not diff-marked. 35) Section 9.3.2 - how should we handle XML event handlers contained at root level under a repeat or a non-xforms element with repeat attrs? Like itemset (listeners registered on the repeat rows and not on the repeat itself)? This has been filed as a separate issue and will be answered later. 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions contained by an itemset to handle events on the itemset." It seems odd that an XForms action OUTSIDE the itemset can handle events on the itemset. And non-XForms actions in the itemset won't be repeated under the anonymous items. For example, the xhtml or xml events 'handler' element would be nice to have repeated to allow the form author to handle xforms-select and xforms-deselect events with script. This has been filed as a separate issue and will be answered later. 37) Section 9.3.5 - if we are inserting attributes, why does the order matter? I didn't think that attribute order was guaranteed to be honored in DOM. Fixed. Diff-marked. For attributes, we define the target location as the full attribute axis, so that the insertion does not specify where the new attribute nodes will go. We believe Xpath supports identifying an attribute by position at a moment in time, but we agree that it may not be possible for an implementation to guarantee the positioning across a mutation of the data model. 38) Section 9.3.5 - the example with the repeat - there needs to be @id="R" on the repeat or the example won't work since the xf:insert uses the index() XPath extension function. Fixed. Not diff-marked. 39) Section 9.3.7 - "if the index evaluates to NaN the action has no effect." The 'if' starts the sentence but isn't capitalized. Fixed. Not diff-marked.
PROBLEM ID: 23
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> The following paragraph in section 9.3.8 should be removed: The binding expression attached to the repeating sequence returns a node-set of the collection being populated, not an individual node. Within the body of element repeat, binding expressions are evaluated with a context node of the node determined by the index. Repeat processing uses XPath expressions to address the collection over which element repeat operates. The first and third sentences are obvious given other material in Section 9, and the second sentence is old and wrong, contradicting the copious material in Section 7.4 on evaluation context (see esp. point 2c and 2d in 7.4). John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> The working group agreed to the removal of the paragraph. > The following paragraph in section 9.3.8 should be removed: > > The binding expression attached to the repeating sequence returns a > node-set of the collection being populated, not an individual node. Within > the body of element repeat, binding expressions are evaluated with a > context node of the node determined by the index. Repeat processing uses > XPath expressions to address the collection over which element repeat > operates. > > The first and third sentences are obvious given other material in Section > 9, and the second sentence is old and wrong, contradicting the copious > material in Section 7.4 on evaluation context (see esp. point 2c and 2d in > 7.4). > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > >
PROBLEM ID: 26
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Ivan Latysh" <IvanLatysh@yahoo.ca> Hello All, As we discussed on www-forms@w3.org mailing list, <repeat/> element has restrictions on node-set that it can operate with, since such limitation has been made to simplify insert and delete elements and now insert and delete can operate with arbitrary node-sets I propose to lift such restriction from <repeat/> element and make it work with arbitrary node-set as insert and delete do. -- Best regards, Ivan mailto:IvanLatysh@yahoo.ca
FOLLOWUP 1:
From: Mail Delivery Subsystem <MAILER-DAEMON@aptest.com> This is a MIME-encapsulated message --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Wed, 13 Jun 2007 08:26:57 -0500 from htmlwg.mn.aptest.com [127.0.0.1] ----- Transcript of session follows ----- 451 4.4.1 reply: read error from a.mx.mail.yahoo.com. ... while talking to g.mx.mail.yahoo.com.: <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html ... while talking to d.mx.mail.yahoo.com.: >>> DATA <<< 451 Message temporarily deferred - [70] ... while talking to b.mx.mail.yahoo.com.: <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html ... while talking to c.mx.mail.yahoo.com.: >>> QUIT <<< 421 Message from (208.42.66.11) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html ... while talking to e.mx.mail.yahoo.com.: >>> DATA <<< 421 Message temporarily deferred - 4.16.51. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html <IvanLatysh@yahoo.ca>... Deferred Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com Content-Type: message/delivery-status Reporting-MTA: dns; htmlwg.mn.aptest.com Arrival-Date: Wed, 13 Jun 2007 08:26:57 -0500 Final-Recipient: RFC822; IvanLatysh@yahoo.ca Action: delayed Status: 4.4.2 Remote-MTA: DNS; e.mx.mail.yahoo.com Last-Attempt-Date: Wed, 13 Jun 2007 12:44:28 -0500 Will-Retry-Until: Mon, 18 Jun 2007 08:26:57 -0500 --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com Content-Type: message/rfc822 Return-Path: <xforms-issues@mn.aptest.com> Received: from localhost (htmlwg.mn.aptest.com [127.0.0.1]) by htmlwg.mn.aptest.com (8.13.1/8.13.1) with ESMTP id l5DDQvrF001703 for <IvanLatysh@yahoo.ca>; Wed, 13 Jun 2007 08:26:57 -0500 Date: Wed, 13 Jun 2007 08:26:57 -0500 Message-Id: <200706131326.l5DDQvrF001703@htmlwg.mn.aptest.com> From: xforms-issues@mn.aptest.com To: IvanLatysh@yahoo.ca Subject: Re: Request for an update for <repeat/> element. (PR#26) X-Loop: xforms-issues@mn.aptest.com Your issue has been added to the W3C's Forms Working Group Issue Tracking System. If you have further information about this issue to report, please reply to this message so that the additional data can be automatically attached to the original query. If you would like to check on the status of this issue, select the following link: http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues?findid=26 This link will take you to a page that shows your issue and its status. If you would like to check on the other issues in the system, you can do so via the web at http://htmlwg.mn.aptest.com/xforms-issues --l5DHSOco003364.1181756668/htmlwg.mn.aptest.com--
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Ivan, The working group agreed that the "homogeneous collection" language in "repeat" was no longer necessary, so the restriction has been removed. Please see the latest editor's draft available from the working group home page and via this link: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html We trust that this change is satisfactory to you. Please let us know if you have any further concerns about this issue. Best regards, John Boyer > > Hello All, > > As we discussed on www-forms@w3.org mailing list, <repeat/> element has > restrictions on node-set that it can > operate with, since such limitation has been made to simplify insert and > delete elements and now insert and delete can > operate with arbitrary node-sets I propose to lift such restriction from > <repeat/> element and make it work with > arbitrary node-set as insert and delete do. > > -- > Best regards, > Ivan mailto:IvanLatysh@yahoo.ca > >
PROBLEM ID: 153
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: aaronr@us.ibm.com Full_Name: Aaron Reed Submission from: (NULL) (32.97.110.142) Submitted by: boyerj 35) Section 9.3.2 - how should we handle XML event handlers contained at root level under a repeat or a non-xforms element with repeat attrs? Like itemset (listeners registered on the repeat rows and not on the repeat itself)? 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions contained by an itemset to handle events on the itemset." It seems odd that an XForms action OUTSIDE the itemset can handle events on the itemset. And non-XForms actions in the itemset won't be repeated under the anonymous items. For example, the xhtml or xml events 'handler' element would be nice to have repeated to allow the form author to handle xforms-select and xforms-deselect events with script.
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Aaron, Spec ready solutions are now available for both of these issues in the editor's draft. [1] (9.3.3 Repeat Processing and 9.3.6 The itemset Element) 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. Regards, Nick Van den Bleeken [1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#ui-repeat-module > Full_Name: Aaron Reed > Submission from: (NULL) (32.97.110.142) > Submitted by: boyerj > > > 35) Section 9.3.2 - how should we handle XML event handlers contained at > root level under a repeat or a non-xforms element with repeat attrs? Like > itemset (listeners registered on the repeat rows and not on the repeat > itself)? > > 36) Section 9.3.3 - "An XForms processor must not allow XForms Actions > contained by an itemset to handle events on the itemset." It seems odd > that an XForms action OUTSIDE the itemset can handle events on the itemset. > And non-XForms actions in the itemset won't be repeated under the anonymous > items. For example, the xhtml or xml events 'handler' element would be > nice to have repeated to allow the form author to handle xforms-select and > xforms-deselect events with script. > >
PROBLEM ID: 143
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> H. Clearly there is a need to provide backwards compatibility with XForms 1.0 in the set of additional functions provided. (It's a shame that these weren't defined to be in their own namespace). However, we would also like to see some kind of migration strategy that moves users forward to the XPath 2.0 replacements for these functions where these exist. For example, xs:boolean() in XPath 2.0 is identical to boolean-from-string() in XForms. (On a point of detail, the values "true" and "false" in XML Schema are case-sensitive whereas this function is described as case-insensitive). A possible migration strategy might start by putting these functions in a separate namespace, and giving users some way to select the function namespaces they want to use in their application. We have not actually checked how many of the additional functions were already defined in XForms 1.0.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, 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. Best regards, John Boyer > > > > H. Clearly there is a need to provide backwards compatibility with > XForms 1.0 in the set of additional functions provided. (It's a > shame that these weren't defined to be in their own > namespace). However, we would also like to see some kind of > migration strategy that moves users forward to the XPath 2.0 > replacements for these functions where these exist. For example, > xs:boolean() in XPath 2.0 is identical to boolean-from-string() in > XForms. (On a point of detail, the values "true" and "false" in > XML Schema are case-sensitive whereas this function is described as > case-insensitive). > > A possible migration strategy might start by putting these > functions in a separate namespace, and giving users some way to > select the function namespaces they want to use in their > application. > > We have not actually checked how many of the additional functions were > already defined in XForms 1.0. > > > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Michael, 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. Best regards, John Boyer > > > > H. Clearly there is a need to provide backwards compatibility with > XForms 1.0 in the set of additional functions provided. (It's a > shame that these weren't defined to be in their own > namespace). However, we would also like to see some kind of > migration strategy that moves users forward to the XPath 2.0 > replacements for these functions where these exist. For example, > xs:boolean() in XPath 2.0 is identical to boolean-from-string() in > XForms. (On a point of detail, the values "true" and "false" in > XML Schema are case-sensitive whereas this function is described as > case-insensitive). > > A possible migration strategy might start by putting these > functions in a separate namespace, and giving users some way to > select the function namespaces they want to use in their > application. > > We have not actually checked how many of the additional functions were > already defined in XForms 1.0. > > > >
PROBLEM ID: 107
STATE: Suspended
EDIT: None
RESOLUTION: Defer
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Jurgis Lukss" <jlukss@gmail.com> Hello, By using last chance to send my comments on XForms working draft, I wanted to clarify following issue. I'm using XForms for at least the last two quarters of a year in our projects and numerous times I have been saved by following XPath 2.0 feature: http://www.w3.org/TR/xpath20/#id-for-expressions I believe this is only way to bind two parallel nodeset tree's children. For example: If I have following XML structure: <rootnode> <nodeset1> <element_type_1 id="1">value 1</element_type_1> <element_type_1 id="2">value 2</element_type_1> </nodeset1> <nodeset2> <element_type_2 ref_id="1" /> <element_type_2 ref_id="2" /> </nodeset2> </rootnode> Now, if I want output value of element_type_2 and value of element_type_1 with matching @ref_id=@id using xforms:repeat and xforms:output. I could find only one solution: <xforms:repeat ref="/rootnode/nodeset2/element_type_2"> <xforms:output value="." /> <xforms:output value="for $el_id in ./@ref_id return (/rootnode/nodeset1/element_type_1[@id=$el_id])" /> </xforms:repeat> I believe that this will be a common problem if XForms were to be used more often and by many more developers. And it would be worth considering including at least this functionality, if not whole XPath 2.0, in XForms 1.1recommendation. But if there is any other or even a trivial solution to this problem, then it should be included as an example. - Jurgis Lukss
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Jurgis, XPath 2.0 features, though valuable, are not in scope of the XForms 1.1 requirements, so we accept this as for XForms 1.2 future features. Regards, Ulrich Nicolas Lissé. For the Form WG > Hello, > > By using last chance to send my comments on XForms working draft, I wanted > to clarify following issue. I'm using XForms for at least the last two > quarters of a year in our projects and numerous times I have been saved by > following XPath 2.0 feature: > http://www.w3.org/TR/xpath20/#id-for-expressions > > I believe this is only way to bind two parallel nodeset tree's children. > For > example: > If I have following XML structure: > > <rootnode> > <nodeset1> > <element_type_1 id="1">value 1</element_type_1> > <element_type_1 id="2">value 2</element_type_1> > </nodeset1> > <nodeset2> > <element_type_2 ref_id="1" /> > <element_type_2 ref_id="2" /> > </nodeset2> > </rootnode> > > > Now, if I want output value of element_type_2 and value of element_type_1 > with matching @ref_id=@id using xforms:repeat and xforms:output. I could > find only one solution: > > <xforms:repeat ref="/rootnode/nodeset2/element_type_2"> > <xforms:output value="." /> > <xforms:output value="for $el_id in ./@ref_id return > (/rootnode/nodeset1/element_type_1[@id=$el_id])" /> > </xforms:repeat> > > I believe that this will be a common problem if XForms were to be used more > often and by many more developers. And it would be worth considering > including at least this functionality, if not whole XPath 2.0, in > XForms 1.1recommendation. But if there is any other or even a trivial > solution to this > problem, then it should be included as an example. > > > - Jurgis Lukss > >
PROBLEM ID: 71
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
See reply.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-choose Please explain that this is a variant of if() that returns objects rather than strings.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Steven, The working group agreed to modify and accept this last call comment. Due to anticipation of name conflict with the XPath 2.0 'if' construct once XForms migrates to XPath 2.0, it was deemed necessary to deprecate if() and encourage use of choose() in the future. Still the relationship between choose() and if(), along with which one is most appropriate to use, has been clarified, which we believe was the intent of this LC comment. Please see the editor's draft available from the working group home page and specifically Section 7.10.1. Thank you, John Boyer > > http://www.w3.org/TR/xforms11/#fn-choose > > Please explain that this is a variant of if() that returns objects > rather than strings. > >
PROBLEM ID: 149
STATE: Suspended
EDIT: None
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> N. The two-argument id() function poses particular problems because its semantics are very similar but not identical to the two-argument id() function in XPath 2.0
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, 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. Regards, Nick Van den Bleeken > N. The two-argument id() function poses particular problems because > its semantics are very similar but not identical to the > two-argument id() function in XPath 2.0 > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, 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. Regards, Nick Van den Bleeken > N. The two-argument id() function poses particular problems because > its semantics are very similar but not identical to the > two-argument id() function in XPath 2.0 > >
PROBLEM ID: 65
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63 Steven was in the room and agreed.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-now Please give examples
PROBLEM ID: 41
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, This is a follow-up to the thread on using index() in UI bindings [1] that focuses on issues with binding expressions in the spec. I already pointed out that section 7.5.1 is broken [2] (private link), and the XSL and XQuery Working Group has some releated LC comment on this as well [3]. Here are some further thoughs: 1. Intro to 7.5 says: "By default, all binding expressions refer to the first instance within the context model. This behavior can be changed with the instance() function." Is this still the right place for this sentence? This is noise I think since we have an improved section "7.4 Evaluation Context". I would recommend removing that sentence and possibly point to 7.4. 2. Section "7.5.1 Dynamic Dependencies" This section needs to be entirely rewritten IMO. In addition to the points raised in [2] and [3]: * "In particular, there are restrictions on model binding expressions that create dynamic dependencies [...]". This concerns Model Binding Expressions so should be removed, or rewritten and integrated into "7.5.2 Model Binding Expressions". I think that 7.5.1 must simply contain a clearer definition of a dynamic dependency, a rationale for the distinction, and at least one example (could be part of the rationale). 3. Section "7.5.2 Model Binding Expressions" Is any XPath expression on xforms:bind a Model Binding Expressions? I thought only @nodeset expressions were called Model Binding Expressions but I seem to be wrong. If not, then @calculate, @constraint, are also MBEs? This is surprising because section ".5.4 The xforms-compute-exception Event" says: "an error occurring during XPath evaluation for a model item property" And section "7.6 The XForms Function Library" also mentions something along these lines. So binding expressions do not necessarly throw binding exceptions? This sounds incoherent. Maybe the confusion stems from the fact that "binding expression" can be interpreted either as "an expression that binds", i.e. on @ref or @nodeset, but also as "an expression on xforms:bind". I think all this needs to be clarified. As mentioned in a separate LC comment [4], there seems to be a general lack of clarity about binding and compute exceptions. 4. Section "7.5.3 UI Binding Expressions": "Dynamic dependences are allowed in UI binding expressions based on the conformance profile." I have no idea what the second part of the sentence means. The term "conformance profile" occurs only twice in the whole spec, and is not defined AFAICT. "XForms Full" is defined as a "conformance level", not as a "conformance profile". Furthermore, even with a definition, "based on the conformance profile" is way too vague. If supporting dynamic dependencies is a feature optional in certain profiles, we can say that. However, section "12.4.2 XForms Full" does not mention that XForms Full must support dynamic dependencies. This section should also precise the notion of dependency for UI bindings. In [1] John mentions that: "dependencies are established based on references to nodes of instance data (in 4.3.6)." But 4.3.6 regards only xforms-recalculate, and it is not clear that it applies to UI bindings. 5. Section "4.3.4 The xforms-refresh Event": "3. All UI bindings should be reevaluated as necessary." "as necessary" needs to be made (much) clearer. 6. Section "4.6.7 Sequence: Value Change": "xforms-refresh performs reevaluation of UI binding expressions" This would be where "as necessary" would be less out of place ;-) -Erik [1] http://lists.w3.org/Archives/Public/public-forms/2007May/0008.html [2] http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0053.html [3] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html [4] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.html -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Erik, The working group accepted all of your points as issues needing work. In particular, notions of dynamic dependency and model binding expression were rigorously defined. The results are now available in the editor's draft at http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html Please let us know if you have any further concerns about these issues. Thank you, John Boyer > > All, > > This is a follow-up to the thread on using index() in UI bindings [1] > that focuses on issues with binding expressions in the spec. > > I already pointed out that section 7.5.1 is broken [2] (private link), > and the XSL and XQuery Working Group has some releated LC comment on > this as well [3]. > > Here are some further thoughs: > > 1. Intro to 7.5 says: > > "By default, all binding expressions refer to the first instance > within the context model. This behavior can be changed with the > instance() function." > > Is this still the right place for this sentence? This is noise I > think since we have an improved section "7.4 Evaluation Context". > > I would recommend removing that sentence and possibly point to 7.4. > > 2. Section "7.5.1 Dynamic Dependencies" > > This section needs to be entirely rewritten IMO. In addition to the > points raised in [2] and [3]: > > * "In particular, there are restrictions on model binding > expressions that create dynamic dependencies [...]". This > concerns Model Binding Expressions so should be removed, or > rewritten and integrated into "7.5.2 Model Binding Expressions". > > I think that 7.5.1 must simply contain a clearer definition of a > dynamic dependency, a rationale for the distinction, and at least > one example (could be part of the rationale). > > 3. Section "7.5.2 Model Binding Expressions" > > Is any XPath expression on xforms:bind a Model Binding Expressions? > I thought only @nodeset expressions were called Model Binding > Expressions but I seem to be wrong. If not, then @calculate, > @constraint, are also MBEs? > > This is surprising because section ".5.4 The > xforms-compute-exception Event" says: > > "an error occurring during XPath evaluation for a model item > property" > > And section "7.6 The XForms Function Library" also mentions > something along these lines. > > So binding expressions do not necessarly throw binding exceptions? > This sounds incoherent. Maybe the confusion stems from the fact > that "binding expression" can be interpreted either as "an > expression that binds", i.e. on @ref or @nodeset, but also as "an > expression on xforms:bind". > > I think all this needs to be clarified. As mentioned in a separate > LC comment [4], there seems to be a general lack of clarity about > binding and compute exceptions. > > 4. Section "7.5.3 UI Binding Expressions": > > "Dynamic dependences are allowed in UI binding expressions based on > the conformance profile." > > I have no idea what the second part of the sentence means. The term > "conformance profile" occurs only twice in the whole spec, and is > not defined AFAICT. "XForms Full" is defined as a "conformance > level", not as a "conformance profile". > > Furthermore, even with a definition, "based on the conformance > profile" is way too vague. If supporting dynamic dependencies is a > feature optional in certain profiles, we can say that. However, > section "12.4.2 XForms Full" does not mention that XForms Full must > support dynamic dependencies. > > This section should also precise the notion of dependency for UI > bindings. In [1] John mentions that: > > "dependencies are established based on references to nodes of > instance data (in 4.3.6)." > > But 4.3.6 regards only xforms-recalculate, and it is not clear that > it applies to UI bindings. > > 5. Section "4.3.4 The xforms-refresh Event": > > "3. All UI bindings should be reevaluated as necessary." > > "as necessary" needs to be made (much) clearer. > > 6. Section "4.6.7 Sequence: Value Change": > > "xforms-refresh performs reevaluation of UI binding expressions" > > This would be where "as necessary" would be less out of place ;-) > > -Erik > > [1] http://lists.w3.org/Archives/Public/public-forms/2007May/0008.html > [2] http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0053.html > [3] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0052.html > [4] http://lists.w3.org/Archives/Public/www-forms-editor/2007Apr/0059.html > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, We will defer the adoption of XPath 2.0 until a later version (probably XForms 2.0) due to reasons we mentioned in an earlier reply. Therefore we can't use the XPath 2.0 description of evaluation context. Moreover the evaluation context section (now 7.2) is also 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. Regards, Nick Van den Bleeken > > F. The XPath 2.0 specification provides a much more formal and > comprehensive description of the evaluation context, which would > provide a more solid basis for this part of the specification. > (: You could use this as a guide even for XPath 1.0 :) > >
PROBLEM ID: 69
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Disagree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-local-date http://www.w3.org/TR/xforms11/#fn-local-dateTime I don't understand the difference between these and the function now(). Please give examples along the lines of "if now() returns "...." then local-DateTime would return "...""
FOLLOWUP 1:
From: "Steven Pemberton" <steven.pemberton@cwi.nl> > Steven, > > We will add examples to show that now() returns Z time only Just for the record, I think this is a bad idea. I understand (now) that the current text for now() is ambiguous, but I believe the wrong interpretation had been chosen to solve that ambiguity. Either way some implementations will have to change, so I think changes should be chosen on what is best for authors, and I believe that most authors will expect now() to return the local time (not UTC), amongst other reasons because that is what spreadsheets return for the function now(). I do however agree there is a use case for a function that returns UTC. Best wishes, Steven Pemberton and add > examples of > local-dateTime() showing that the returned result is in the local > timezone. > > The difference between now() and local-dateTime() is basically whether > or not > the returned value is just in the zulu timezone or the local timezone. > > Regards, > > Nick Van den Bleeken > >> >> http://www.w3.org/TR/xforms11/#fn-local-date >> http://www.w3.org/TR/xforms11/#fn-local-dateTime >> >> I don't understand the difference between these and the function now(). >> >> Please give examples along the lines of "if now() returns "...." then >> local-DateTime would return "..."" >> >>
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, We will add examples to show that now() returns Z time only and add examples of local-dateTime() showing that the returned result is in the local timezone. The difference between now() and local-dateTime() is basically whether or not the returned value is just in the zulu timezone or the local timezone. Regards, Nick Van den Bleeken > > http://www.w3.org/TR/xforms11/#fn-local-date > http://www.w3.org/TR/xforms11/#fn-local-dateTime > > I don't understand the difference between these and the function now(). > > Please give examples along the lines of "if now() returns "...." then > local-DateTime would return "..."" > >
PROBLEM ID: 68
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-digest Why bother with all the alternatives for the parameter? Why not just md5/sha1/sha256/sha384/sha512 In the examples the function has the wrong name.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The working group reduced the number of alternatives to one per hash algorithm as requested. The only difference is that the keywords chosen were based on the algorithm names as given in their specifications: MD5, SHA-1, SHA-256, SHA-384 and SH-512. The examples were also corrected. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#fn-digest > > Why bother with all the alternatives for the parameter? Why not just > md5/sha1/sha256/sha384/sha512 > > In the examples the function has the wrong name. > >
PROBLEM ID: 146
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> K. The decode() function needs to define an additional error, for the case where the data can be decoded as a UTF-8 character string but that string contains a character not allowed in XML. The name of the encode() function is much too generic, and should be renamed to something that indicates its purpose more clearly. In the description of the encode() function, "The data string is serialized as UTF-8" is ambiguous - it might mean (a) the parameter must be UTF-8, or (b) the function serializes the input string as UTF-8. Also, UTF-8 is hard-coded. There are other possibilities. The phrase "string of data" is redundant; you can simply say "string". In XPath 2.0, you would probably want to have two functions - one would return the base64 binary representation, the other would return the hex binary representation. Conversion of the binary to a string would be done by the string() function. These two functions are candidates for incorporating into XPath 2.N core. We would be interested in working with you on the design of these two functions.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Michael, The working group solved this issue indirectly. We found it necessary to remove the functions encode() and decode(). Although they seem like they could be useful, the decode function can produce results that do not fit the XPath data model's restriction to XML Char, which means that encode() would need to take illegal string data in order to be fully functional. Best regards, John Boyer > > > K. The decode() function needs to define an additional error, for > the case where the data can be decoded as a UTF-8 character string > but that string contains a character not allowed in XML. > > The name of the encode() function is much too generic, and should > be renamed to something that indicates its purpose more clearly. In > the description of the encode() function, "The data string is > serialized as UTF-8" is ambiguous - it might mean (a) the parameter > must be UTF-8, or (b) the function serializes the input string as > UTF-8. > > Also, UTF-8 is hard-coded. There are other possibilities. > > The phrase "string of data" is redundant; you can simply say > "string". > > In XPath 2.0, you would probably want to have two functions - one > would return the base64 binary representation, the other would > return the hex binary representation. Conversion of the binary to a > string would be done by the string() function. > > These two functions are candidates for incorporating into XPath 2.N > core. We would be interested in working with you on the design of > these two functions. > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Michael, The working group solved this issue indirectly. We found it necessary to remove the functions encode() and decode(). Although they seem like they could be useful, the decode function can produce results that do not fit the XPath data model's restriction to XML Char, which means that encode() would need to take illegal string data in order to be fully functional. Best regards, John Boyer > > > K. The decode() function needs to define an additional error, for > the case where the data can be decoded as a UTF-8 character string > but that string contains a character not allowed in XML. > > The name of the encode() function is much too generic, and should > be renamed to something that indicates its purpose more clearly. In > the description of the encode() function, "The data string is > serialized as UTF-8" is ambiguous - it might mean (a) the parameter > must be UTF-8, or (b) the function serializes the input string as > UTF-8. > > Also, UTF-8 is hard-coded. There are other possibilities. > > The phrase "string of data" is redundant; you can simply say > "string". > > In XPath 2.0, you would probably want to have two functions - one > would return the base64 binary representation, the other would > return the hex binary representation. Conversion of the binary to a > string would be done by the string() function. > > These two functions are candidates for incorporating into XPath 2.N > core. We would be interested in working with you on the design of > these two functions. > >
PROBLEM ID: 140
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> E. "A future version of XForms is expected to use XPath 2.0". We think it would be more appropriate to use XPath 2.0 in the current version. Even if you choose not to use XPath 2.0 now, we think you should consider laying the groundwork for a transition to XPath 2.0 in the current version. (: We noted that there are a few areas where transition to 2.0 will cause some compatibility problems - some of these are noted below. In these areas in particular we think it would be useful if XForms 1.1 provided alternatives to the current 1.0 syntax in a way that eases transition to XPath 2.0 later :)
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, We will defer the adoption of XPath 2.0 until a later version (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. Regards, Nick Van den Bleeken > > > E. "A future version of XForms is expected to use XPath 2.0". We > think it would be more appropriate to use XPath 2.0 in the current > version. > > Even if you choose not to use XPath 2.0 now, we think you should > consider laying the groundwork for a transition to XPath 2.0 in the > current version. (: We noted that there are a few areas where transition > to 2.0 will cause some compatibility problems - some of these are noted > below. In these areas in particular we think it would be useful if > XForms 1.1 provided alternatives to the current 1.0 syntax in a way > that eases transition to XPath 2.0 later :) > > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, We will defer the adoption of XPath 2.0 until a later version (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. Regards, Nick Van den Bleeken > > > E. "A future version of XForms is expected to use XPath 2.0". We > think it would be more appropriate to use XPath 2.0 in the current > version. > > Even if you choose not to use XPath 2.0 now, we think you should > consider laying the groundwork for a transition to XPath 2.0 in the > current version. (: We noted that there are a few areas where transition > to 2.0 will cause some compatibility problems - some of these are noted > below. In these areas in particular we think it would be useful if > XForms 1.1 provided alternatives to the current 1.0 syntax in a way > that eases transition to XPath 2.0 later :) > > >
PROBLEM ID: 40
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> The text "then an xforms-binding exception occurs." should read "then an xforms-binding-exception occurs." (missing "-"). -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, We will defer the adoption of XPath 2.0 until a later version (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. Regards, Nick Van den Bleeken > > > E. "A future version of XForms is expected to use XPath 2.0". We > think it would be more appropriate to use XPath 2.0 in the current > version. > > Even if you choose not to use XPath 2.0 now, we think you should > consider laying the groundwork for a transition to XPath 2.0 in the > current version. (: We noted that there are a few areas where transition > to 2.0 will cause some compatibility problems - some of these are noted > below. In these areas in particular we think it would be useful if > XForms 1.1 provided alternatives to the current 1.0 syntax in a way > that eases transition to XPath 2.0 later :) > > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, We will defer the adoption of XPath 2.0 until a later version (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. Regards, Nick Van den Bleeken > > > E. "A future version of XForms is expected to use XPath 2.0". We > think it would be more appropriate to use XPath 2.0 in the current > version. > > Even if you choose not to use XPath 2.0 now, we think you should > consider laying the groundwork for a transition to XPath 2.0 in the > current version. (: We noted that there are a few areas where transition > to 2.0 will cause some compatibility problems - some of these are noted > below. In these areas in particular we think it would be useful if > XForms 1.1 provided alternatives to the current 1.0 syntax in a way > that eases transition to XPath 2.0 later :) > > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Erik, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > The text "then an xforms-binding exception occurs." should read "then an > xforms-binding-exception occurs." (missing "-"). > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 139
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
ACTION: Erik to address this with expanded wording about failure on undefined variable references and function calls.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> D. "XPath expressions that are not syntactically valid": should cover all static errors, not just syntax errors. (Other static errors include, for example, references to functions or variables not present in the context, and type errors detected statically).
FOLLOWUP 1:
From: "Michael Kay" <mike@saxonica.com> That's fine. Undefined namespace prefixes are another possibility, in case you are enumerating them. In fact XPath 1.0 doesn't distinguish very carefully between static and dynamic errors, so count("xyz") is an error that can be reported either statically or dynamically, similarly ($x|3). Michael Kay > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 24 October 2007 20:00 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: Section 7 (PR#139) > > Hi Michael, > > The working group agrees that this is a problem and will fix > it in the specification. For XPath 1.0, the static errors > appear to be limited to expression well-formedness, undefined > variable references and undefined function references as > issues with the [context node, position, size] are handled > separately, i.e. their non-availability implies not executing > the xpath and behaving as if empty nodeset were returned. > > Please let us know if you have any further concerns about this issue. > > Thank you, > John Boyer > > > > > > > > > D. "XPath expressions that are not syntactically valid": should > > cover all static errors, not just syntax errors. (Other static > > errors include, for example, references to functions or > variables > > not present in the context, and type errors detected > statically). > > > > > > > >
FOLLOWUP 2:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Michael, The working group agrees that this is a problem and will fix it in the specification. For XPath 1.0, the static errors appear to be limited to expression well-formedness, undefined variable references and undefined function references as issues with the [context node, position, size] are handled separately, i.e. their non-availability implies not executing the xpath and behaving as if empty nodeset were returned. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > > > D. "XPath expressions that are not syntactically valid": should > cover all static errors, not just syntax errors. (Other static > errors include, for example, references to functions or variables > not present in the context, and type errors detected statically). > > > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Michael, The working group agrees that this is a problem and will fix it in the specification. For XPath 1.0, the static errors appear to be limited to expression well-formedness, undefined variable references and undefined function references as issues with the [context node, position, size] are handled separately, i.e. their non-availability implies not executing the xpath and behaving as if empty nodeset were returned. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > > > D. "XPath expressions that are not syntactically valid": should > cover all static errors, not just syntax errors. (Other static > errors include, for example, references to functions or variables > not present in the context, and type errors detected statically). > > > >
PROBLEM ID: 148
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> M. Typo: "more that one instance"
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- This has been fixed. Thanks, John Boyer > > > > M. Typo: "more that one instance" > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> This has been fixed. Thanks, John Boyer > > > > M. Typo: "more that one instance" > >
PROBLEM ID: 177
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 001CE33088257331_= Content-Type: text/plain; charset="US-ASCII" Erik Bruchez <ebruchez@orbeon.com> Sent by: public-forms-request@w3.org 08/01/2007 02:30 PM Please respond to ebruchez@orbeon.com To "Forms WG (new)" <public-forms@w3.org> cc www-forms-editor@w3.org Subject Comment about location of choose() and event() functions in the spec All, I notice that these two functions are under section "7.11 Node-set Functions". This is not correct, as they can return types other than node-set. The suggested fix is to create a section "7.12 Object Functions" and move the current 7.12 to 7.13. -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/ --=_alternative 001CE33088257331_= Content-Type: text/html; charset="US-ASCII" <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Erik Bruchez <ebruchez@orbeon.com></b> </font> <br><font size=1 face="sans-serif">Sent by: public-forms-request@w3.org</font> <p><font size=1 face="sans-serif">08/01/2007 02:30 PM</font> <table border> <tr valign=top> <td bgcolor=white> <div align=center><font size=1 face="sans-serif">Please respond to<br> ebruchez@orbeon.com</font></div></table> <br> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"Forms WG (new)" <public-forms@w3.org></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">Comment about location of choose() and event() functions in the spec</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> All,<br> <br> I notice that these two functions are under section "7.11 Node-set <br> Functions". This is not correct, as they can return types other than <br> node-set.<br> <br> The suggested fix is to create a section "7.12 Object Functions" and <br> move the current 7.12 to 7.13.<br> <br> -Erik<br> <br> -- <br> Orbeon Forms - Web Forms for the Enterprise Done the Right Way<br> </font></tt><a href=http://www.orbeon.com/><tt><font size=2>http://www.orbeon.com/</font></tt></a><tt><font size=2><br> <br> </font></tt> --=_alternative 001CE33088257331_=--
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Dear Erik, The working group accepts this proposal, and it has been implemented now. Please see section 7.10 of the editor's draft available from the working group home page. Thanks, John Boyer > This is a multipart message in MIME format. > --=_alternative 001CE33088257331_= > Content-Type: text/plain; charset="US-ASCII" > > Erik Bruchez <ebruchez@orbeon.com> > Sent by: public-forms-request@w3.org > 08/01/2007 02:30 PM > Please respond to > ebruchez@orbeon.com > > > To > "Forms WG (new)" <public-forms@w3.org> > cc > www-forms-editor@w3.org > Subject > Comment about location of choose() and event() functions in the spec > > > > > > > > All, > > I notice that these two functions are under section "7.11 Node-set > Functions". This is not correct, as they can return types other than > node-set. > > The suggested fix is to create a section "7.12 Object Functions" and > move the current 7.12 to 7.13. > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > > > --=_alternative 001CE33088257331_= > Content-Type: text/html; charset="US-ASCII" > > > <table width=100%> > <tr valign=top> > <td width=40%><font size=1 face="sans-serif"><b>Erik Bruchez > <ebruchez@orbeon.com></b> > </font> > <br><font size=1 face="sans-serif">Sent by: public-forms-request@w3.org</font> > <p><font size=1 face="sans-serif">08/01/2007 02:30 PM</font> > <table border> > <tr valign=top> > <td bgcolor=white> > <div align=center><font size=1 face="sans-serif">Please respond to<br> > ebruchez@orbeon.com</font></div></table> > <br> > <td width=59%> > <table width=100%> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">To</font></div> > <td><font size=1 face="sans-serif">"Forms WG (new)" > <public-forms@w3.org></font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">cc</font></div> > <td><font size=1 face="sans-serif">www-forms-editor@w3.org</font> > <tr valign=top> > <td> > <div align=right><font size=1 face="sans-serif">Subject</font></div> > <td><font size=1 face="sans-serif">Comment about location of choose() and > event() functions in the spec</font></table> > <br> > <table> > <tr valign=top> > <td> > <td></table> > <br></table> > <br> > <br> > <br><tt><font size=2><br> > All,<br> > <br> > I notice that these two functions are under section "7.11 Node-set > <br> > Functions". This is not correct, as they can return types other than > <br> > node-set.<br> > <br> > The suggested fix is to create a section "7.12 Object Functions" > and <br> > move the current 7.12 to 7.13.<br> > <br> > -Erik<br> > <br> > -- <br> > Orbeon Forms - Web Forms for the Enterprise Done the Right Way<br> > </font></tt><a href=http://www.orbeon.com/><tt><font > size=2>http://www.orbeon.com/</font></tt></a><tt><font size=2><br> > <br> > </font></tt> > --=_alternative 001CE33088257331_=-- > >
PROBLEM ID: 63
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#id-card-type http://www.w3.org/TR/xforms11/#fn-luhn "The complementary XPath function luhn() should be used to validate that the ID number conforms to the specification." I imagine that almost exclusively these will be used like this: <bind nodeset="cc" type="ID-card-number" constraint="luhn()" /> While I applaud the recognition of computer scientists who have contributed to society, I fear that this is too hard to remember for this single occurring case. May I propose as easier to cope with something along the lines of: <bind nodeset="cc" type="card-number" constraint="card-number()" />
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Steven, We will change the Change ID-card-number type to card-number and change name of the luhn() function to is-card-number(). Regards, Nick Van den Bleeken > > http://www.w3.org/TR/xforms11/#id-card-type > http://www.w3.org/TR/xforms11/#fn-luhn > > "The complementary XPath function luhn() should be used to validate > that the ID number conforms to the specification." > > I imagine that almost exclusively these will be used like this: > > <bind nodeset="cc" type="ID-card-number" constraint="luhn()" /> > > While I applaud the recognition of computer scientists who have > contributed to society, I fear that this is too hard to remember for > this single occurring case. May I propose as easier to cope with > something along the lines of: > > <bind nodeset="cc" type="card-number" constraint="card-number()" /> > > >
PROBLEM ID: 44
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
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.
ORIGINAL MESSAGE:
From: "John Boyer" <boyerj@ca.ibm.com> 1.1 has a requirement to allow search for data by a key value. Although the detail text doesn't strictly mention it, I expected that our addition of the while attribute to XForms actions allowed us to do a search of where to put a new piece of data, and the required improvments to insert then allowed us to put it there. We can do this if the "key" is a number, but due to a limitation of XPath that I think we did not really note until recently, we cannot do the same if the key data is a string such as a name. This means it is not possible for an XForm to maintain the ordered nature of a list of data under insert mutation. This is a trivially obvious use case that I *thought* we were accounting for, and it is easily solved by adding a string-compare() function to the XForms function library for XPath, and it should be easy to define it to be compatible with string comparison available in XPath 2.0. Some have complained that since XPath 2 has this, then the right answer is to adopt XPath 2. In principle and in an ideal world, sure we'd get right on that, but we should not leave such a gaping hole in XForms 1.1, which is still based on XPath 1.0. Since XPath 1.0 already contains the desired feature (the extensibility to allow us to define the function we need), there should be nothing wrong with using that feature, esp. if we define a compatible function for later upward mobility. The argument that we shouldn't use the XPath 1.0 feature of extensibility because XPath 2 has this piece of overlapping functionality is problematic because the following conclusion is that we should not add anything since it might conflict with XPath 3.0. If you think this can't happen, observe that it already has-- the if() function we desperately needed now conflicts with XPath 2.0. Conclusion: Please solve the problem that we can only maintain ordered numeric data and not ordered string data by adding a simple string-compare() function. Thanks, John M. Boyer, Ph.D. STSM: Workplace Forms Architect and Researcher Co-Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
FOLLOWUP 1:
From: "Hickey, Marianne" <marianne.hickey@hp.com> I am out of the office on extended leave and am not currently checking email.
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> John, we accepted your proposal and edited the spec accordingly. Regards, Ulrich Lissé For the Forms WG
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, 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. Regards, Nick Van den Bleeken > > I. The if() function poses particular problems because if() is not > allowed as a function name in XPath 2.0 for syntactic reasons. > > If your functions were namespace qualified, this would be no > problem. This is an example where thinking of your transition > strategy to XPath 2.0 would be important. > > >
PROBLEM ID: 144
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Modify and Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> I. The if() function poses particular problems because if() is not allowed as a function name in XPath 2.0 for syntactic reasons. If your functions were namespace qualified, this would be no problem. This is an example where thinking of your transition strategy to XPath 2.0 would be important.
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, 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. Regards, Nick Van den Bleeken > > I. The if() function poses particular problems because if() is not > allowed as a function name in XPath 2.0 for syntactic reasons. > > If your functions were namespace qualified, this would be no > problem. This is an example where thinking of your transition > strategy to XPath 2.0 would be important. > > >
PROBLEM ID: 11
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 7 At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 7.10.1 Require UTC as default for time zone information Comment: The now function returns the current system date and time as a string value in the canonical XML Schema xsd:dateTime format. If time zone information is available, it is included (normalized to UTC). If no time zone information is available, an implementation default is used. Please require that the default is UTC. Otherwise the results of applying this function by different implementations might lead to dateTime values which are not totally ordered. See the Working with Time Zones [http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e448] for further guidance. Btw., in e.g. sec. 7.10.2 \"The days-from-date() Function\" you already require usage of UTC.
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Felix, We accept your comments and will change the text so that it clearly states that if the timezone information is not available, the implementation should return the time with Z appended. Regards, Nick Van den Bleeken > > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 7 > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 7.10.1 > Require UTC as default for time zone information > > Comment: > > The now function returns the current system date and time as a string > value in the canonical XML Schema xsd:dateTime format. If time zone > information is available, it is included (normalized to UTC). If no time > zone information is available, an implementation default is used. > > Please require that the default is UTC. Otherwise the results of applying > this function by different implementations might lead to dateTime values > which are not totally ordered. See the > Working with Time Zones > [http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e448] > for further guidance. Btw., in e.g. sec. 7.10.2 \"The days-from-date() > Function\" you already require usage of UTC. > > > > >
PROBLEM ID: 142
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> G. The concept of "dynamic dependencies" needs further explanation. It's very hard to understand what this section is saying. We believe you need a precise definition that states when there is a dynamic dependency. "there are restrictions on model binding expressions that create dynamic dependencies" -> you should tell us precisely what these restrictions are, and what an implementation should do if these restrictions are violated.
FOLLOWUP 1:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Michael, we accept that a better definition for what happens when you use a dynamic dependency in the model is needed. We created an action item to produce new spec text. Regards, Ulrich Nicolas Lissé For the Forms WG > G. The concept of "dynamic dependencies" needs further > explanation. It's very hard to understand what this section is > saying. We believe you need a precise definition that states when > there is a dynamic dependency. > > "there are restrictions on model binding expressions that create > dynamic dependencies" -> you should tell us precisely what these > restrictions are, and what an implementation should do if these > restrictions are violated. > >
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Michael, we accept that a better definition for what happens when you use a dynamic dependency in the model is needed. We created an action item to produce new spec text. Regards, Ulrich Nicolas Lissé For the Forms WG > G. The concept of "dynamic dependencies" needs further > explanation. It's very hard to understand what this section is > saying. We believe you need a precise definition that states when > there is a dynamic dependency. > > "there are restrictions on model binding expressions that create > dynamic dependencies" -> you should tell us precisely what these > restrictions are, and what an implementation should do if these > restrictions are violated. > >
PROBLEM ID: 33
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
These have been moved to the end of section 4 in the editor's draft.
ORIGINAL MESSAGE:
From: "Mark Birbeck" <mark.birbeck@x-port.net> Section 7 is devoted to all things XPath, which doesn't really seem appropriate for sections 7.2 and 7.3. -- Mark Birbeck, formsPlayer mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Mark, The working group accepts this last call comment and has decided to move the two sections to the end of Chapter 4, which contains all material related to accessing and updating the model. Thank you, John Boyer > > Section 7 is devoted to all things XPath, which doesn't really seem > appropriate for sections 7.2 and 7.3. > > -- > Mark Birbeck, formsPlayer > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > http://www.formsPlayer.com | http://internet-apps.blogspot.com > > standards. innovation. > >
PROBLEM ID: 70
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-get-seconds-from-duration Please don't start examples off with an error case like this. First give some valid examples, and then some error examples (in the case of this first one because the parameter only contains years and months). Is there a rationale for why such examples return 0 instead of NaN?
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, These examples were from XForms 1.0. The order has been changed to start with a non-error case, and the updated example style for XForms 1.1 has been applied, which necessitated adding an explanation for the return values. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#fn-get-seconds-from-duration > > Please don't start examples off with an error case like this. First > give some valid examples, and then some error examples (in the case of > this first one because the parameter only contains years and months). > > Is there a rationale for why such examples return 0 instead of NaN? > >
PROBLEM ID: 12
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Agree
NOTES:
Process the following issues together : XPath/11, XPath/12, XPath/69, XPath/63
ORIGINAL MESSAGE:
From: fsasaki@w3.org Comment from the i18n review of: http://www.w3.org/TR/2007/WD-xforms11-20070222/ Comment 8. At http://www.w3.org/International/reviews/0704-xforms11/ Editorial/substantive: S Location in reviewed document: 7.10.6 and 7.10.7 Availability of time zone information unclear Comment: Sec. 7.10.6 contains the statement: This function returns a lexical xsd:date obtained as if by the following rules: the result of now() is converted to a local date based on the user agent time zone information. > From this statement it is unclear what kind of indicator the user agent > should use to provide time zone information. The same unclearness is in > sec.7.10.7.
REPLY 1:
From: Ulrich Nicolas Lissé <xforms-issues@mn.aptest.com> Hello, the method by which the XForms processor gets the timezone info from the user agent is not specified because it is implementation-defined. Regards, Ulrich Nicolas Lissé. For the Forms WG > Comment from the i18n review of: > http://www.w3.org/TR/2007/WD-xforms11-20070222/ > > Comment 8. > At http://www.w3.org/International/reviews/0704-xforms11/ > Editorial/substantive: S > Location in reviewed document: > 7.10.6 and 7.10.7 > Availability of time zone information unclear > > Comment: > > Sec. 7.10.6 contains the statement: > > > This function returns a lexical xsd:date obtained as if by the following > rules: the result of now() is converted to a local date based on the user > agent time zone information. > >> From this statement it is unclear what kind of indicator the user agent >> should use to provide time zone information. The same unclearness is in >> sec.7.10.7. > > > > >
PROBLEM ID: 39
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> The text "Dynamic dependences" should read "Dynamic dependencies". -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
FOLLOWUP 1:
From: "Michael Kay" <mike@saxonica.com> That's fine. Undefined namespace prefixes are another possibility, in case you are enumerating them. In fact XPath 1.0 doesn't distinguish very carefully between static and dynamic errors, so count("xyz") is an error that can be reported either statically or dynamically, similarly ($x|3). Michael Kay > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 24 October 2007 20:00 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: Section 7 (PR#139) > > Hi Michael, > > The working group agrees that this is a problem and will fix > it in the specification. For XPath 1.0, the static errors > appear to be limited to expression well-formedness, undefined > variable references and undefined function references as > issues with the [context node, position, size] are handled > separately, i.e. their non-availability implies not executing > the xpath and behaving as if empty nodeset were returned. > > Please let us know if you have any further concerns about this issue. > > Thank you, > John Boyer > > > > > > > > > D. "XPath expressions that are not syntactically valid": should > > cover all static errors, not just syntax errors. (Other static > > errors include, for example, references to functions or > variables > > not present in the context, and type errors detected > statically). > > > > > > > >
FOLLOWUP 2:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Michael, The working group agrees that this is a problem and will fix it in the specification. For XPath 1.0, the static errors appear to be limited to expression well-formedness, undefined variable references and undefined function references as issues with the [context node, position, size] are handled separately, i.e. their non-availability implies not executing the xpath and behaving as if empty nodeset were returned. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > > > D. "XPath expressions that are not syntactically valid": should > cover all static errors, not just syntax errors. (Other static > errors include, for example, references to functions or variables > not present in the context, and type errors detected statically). > > > >
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Erik, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > The text "Dynamic dependences" should read "Dynamic dependencies". > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
REPLY 2:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Michael, The working group agrees that this is a problem and will fix it in the specification. For XPath 1.0, the static errors appear to be limited to expression well-formedness, undefined variable references and undefined function references as issues with the [context node, position, size] are handled separately, i.e. their non-availability implies not executing the xpath and behaving as if empty nodeset were returned. Please let us know if you have any further concerns about this issue. Thank you, John Boyer > > > > D. "XPath expressions that are not syntactically valid": should > cover all static errors, not just syntax errors. (Other static > errors include, for example, references to functions or variables > not present in the context, and type errors detected statically). > > > >
PROBLEM ID: 152
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
ORIGINAL MESSAGE:
From: Leigh.klotz@Xerox.com Full_Name: Leigh L. Klotz, Jr. Submission from: (NULL) (13.1.101.37) -------------------------------------------------------------------------------- From: John Boyer [mailto:boyerj@ca.ibm.com] Sent: Tuesday, June 19, 2007 12:07 PM To: Klotz, Leigh Cc: public-forms@w3.org Subject: Re: id function and xsi:type Hi Leigh, Can you please make sure this issue is entered into the issue system. Thanks, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Leigh L Klotz, Jr." <Leigh.Klotz@xerox.com> Sent by: www-forms-editor-request@w3.org 06/14/2007 06:31 AM To www-forms-editor@w3.org cc Subject id function and xsi:type In http://www.w3.org/TR/xforms11/#fn-id it says An element node can be assigned an ID by means of an xml:id attribute or an attribute that is assigned the type ID by a DTD or xsd:ID or any type derived from xsd:ID by an XML schema, an xsi:type attribute, or the type model item property. I do not see how xsi:type can be used to assign type xsd:ID to an attribute, since it appears that xsi:type can assign types only to elements. Leigh.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Leigh, You are correct, of course. Please see the diff-marked version now available from the editor's draft section of the Forms WG website, and let us know if you have any further concerns about this issue. Thanks, John Boyer > Full_Name: Leigh L. Klotz, Jr. > Submission from: (NULL) (13.1.101.37) > > > > -------------------------------------------------------------------------------- > From: John Boyer [mailto:boyerj@ca.ibm.com] > Sent: Tuesday, June 19, 2007 12:07 PM > To: Klotz, Leigh > Cc: public-forms@w3.org > Subject: Re: id function and xsi:type > > > > Hi Leigh, > > Can you please make sure this issue is entered into the issue system. > > Thanks, > > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > > > > > "Leigh L Klotz, Jr." <Leigh.Klotz@xerox.com> > Sent by: www-forms-editor-request@w3.org > 06/14/2007 06:31 AM > To www-forms-editor@w3.org > cc > Subject id function and xsi:type > > > > > > > > > In http://www.w3.org/TR/xforms11/#fn-id it says > > An element node can be assigned an ID by means of an xml:id attribute or an > attribute that is assigned the type ID by a DTD or xsd:ID or any type > derived > from xsd:ID by an XML schema, an xsi:type attribute, or the type model item > property. > > I do not see how xsi:type can be used to assign type xsd:ID to an > attribute, since it appears that xsi:type can assign types only to > elements. > > Leigh. > > > > >
PROBLEM ID: 141
STATE: Suspended
EDIT: N/A
RESOLUTION: Defer
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> F. The XPath 2.0 specification provides a much more formal and comprehensive description of the evaluation context, which would provide a more solid basis for this part of the specification. (: You could use this as a guide even for XPath 1.0 :)
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, We will defer the adoption of XPath 2.0 until a later version (probably XForms 2.0) due to reasons we mentioned in an earlier reply. Therefore we can't use the XPath 2.0 description of evaluation context. Moreover the evaluation context section (now 7.2) is also 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. Regards, Nick Van den Bleeken > > F. The XPath 2.0 specification provides a much more formal and > comprehensive description of the evaluation context, which would > provide a more solid basis for this part of the specification. > (: You could use this as a guide even for XPath 1.0 :) > >
PROBLEM ID: 147
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Modify and Accept
USER POSITION: Disagree
NOTES:
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().
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> L. The seconds-from-dateTime() function poses a particular problem because XPath 2.0 offers a function with the same name and different semantics. You should define whether leap second are taken into account, and if so, specify how.
FOLLOWUP 1:
From: "Michael Kay" <mike@saxonica.com> Well, I'm clearly not going to persuade you, but it seems a very short-sighted attitude to me. If the XForms specification doesn't support XPath 2.0 until 2010, then an increasing number of vendors will support it unilaterally (some already do), which means the coexistence and transition issues will be even worse. In any, case, the argument seems a bit like the millenium bug: we won't worry about this problem because it will be three years before users notice it. Michael Kay > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 18 October 2007 09:27 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.10.4 (PR#147) > > Hi Michael, > > I received your follow-up recommending that we add > seconds-from-1970() and deprecate seconds-from-dataTime() to > make future updating to XForms 2.0/XPath 2.0 easier. > > This only seems to add confusing complexities to XForms 1.1 > in order to make at best a minor improvement to the future > update capabilities. The update of 1.x content to XForms 2.0 > should have much bigger issues than this. > It is also by no means clear that a form author undergoing > such a large update of content would even want to retain the > 1970 semantic anyway because the typical call of these > functions is to do date math and comparisons. > > Finally, it should be noted that the current estimated > (optimistic) timeframe for an XForms 2.0 recommendation is > the end of 2010. > > Best regards, > John Boyer > > > > > > > L. The seconds-from-dateTime() function poses a > particular problem > > because XPath 2.0 offers a function with the same name and > > different semantics. > > > > You should define whether leap second are taken into > account, and > > if so, specify how. > > > >
FOLLOWUP 2:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Michael, I received your follow-up recommending that we add seconds-from-1970() and deprecate seconds-from-dataTime() to make future updating to XForms 2.0/XPath 2.0 easier. This only seems to add confusing complexities to XForms 1.1 in order to make at best a minor improvement to the future update capabilities. The update of 1.x content to XForms 2.0 should have much bigger issues than this. It is also by no means clear that a form author undergoing such a large update of content would even want to retain the 1970 semantic anyway because the typical call of these functions is to do date math and comparisons. Finally, it should be noted that the current estimated (optimistic) timeframe for an XForms 2.0 recommendation is the end of 2010. Best regards, John Boyer > > > L. The seconds-from-dateTime() function poses a particular problem > because XPath 2.0 offers a function with the same name and > different semantics. > > You should define whether leap second are taken into account, and > if so, specify how. > >
FOLLOWUP 3:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Dear Michael, The seconds-from-dateTime() function 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, we will add text that states that leap seconds are not supported. Regards, Nick Van den Bleeken > > > L. The seconds-from-dateTime() function poses a particular problem > because XPath 2.0 offers a function with the same name and > different semantics. > > You should define whether leap second are taken into account, and > if so, specify how. > >
FOLLOWUP 4:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 0036970F88257378_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, I agree that in the general case, without looking at the specific functions at hand, it might seem very short-sighted. The real question that needs an answer is whether the difference of semantic breaks the real uses cases we have for this function, which are 1) Compare two dates seconds-from-dateTime(D1) < seconds-from-dateTime(D2) 2) Difference, which can be string manipulated into a duration if needed seconds-from-dateTime(D1) - seconds-from-dateTime(D2) 3) Compute 2 hours from now adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) + 7200)) Can you let us know please if you think the difference of semantic will break one of these three expressions? Thank you, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Michael Kay" <mike@saxonica.com> Sent by: www-forms-editor-request@w3.org 10/18/2007 01:53 AM To "'John Boyer'" <xforms-issues@mn.aptest.com> cc <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> Subject RE: 7.10.4 (PR#147) Well, I'm clearly not going to persuade you, but it seems a very short-sighted attitude to me. If the XForms specification doesn't support XPath 2.0 until 2010, then an increasing number of vendors will support it unilaterally (some already do), which means the coexistence and transition issues will be even worse. In any, case, the argument seems a bit like the millenium bug: we won't worry about this problem because it will be three years before users notice it. Michael Kay > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 18 October 2007 09:27 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.10.4 (PR#147) > > Hi Michael, > > I received your follow-up recommending that we add > seconds-from-1970() and deprecate seconds-from-dataTime() to > make future updating to XForms 2.0/XPath 2.0 easier. > > This only seems to add confusing complexities to XForms 1.1 > in order to make at best a minor improvement to the future > update capabilities. The update of 1.x content to XForms 2.0 > should have much bigger issues than this. > It is also by no means clear that a form author undergoing > such a large update of content would even want to retain the > 1970 semantic anyway because the typical call of these > functions is to do date math and comparisons. > > Finally, it should be noted that the current estimated > (optimistic) timeframe for an XForms 2.0 recommendation is > the end of 2010. > > Best regards, > John Boyer > > > > > > > L. The seconds-from-dateTime() function poses a > particular problem > > because XPath 2.0 offers a function with the same name and > > different semantics. > > > > You should define whether leap second are taken into > account, and > > if so, specify how. > > > > --=_alternative 0036970F88257378_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Michael,</font> <br> <br><font size=2 face="sans-serif">I agree that in the general case, without looking at the specific functions at hand, it might seem very short-sighted.</font> <br> <br><font size=2 face="sans-serif">The real question that needs an answer is whether the difference of semantic breaks the real uses cases we have for this function, which are</font> <br> <br><font size=2 face="sans-serif">1) Compare two dates </font> <br><font size=2 face="sans-serif">seconds-from-dateTime(D1) &lt; seconds-from-dateTime(D2)</font> <br> <br><font size=2 face="sans-serif">2) Difference, which can be string manipulated into a duration if needed</font> <br><font size=2 face="sans-serif">seconds-from-dateTime(D1) - seconds-from-dateTime(D2)</font> <br> <br><font size=2 face="sans-serif">3) Compute 2 hours from now</font> <br><font size=2 face="sans-serif">adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) + 7200))</font> <br> <br><font size=2 face="sans-serif">Can you let us know please if you think the difference of semantic will break one of these three expressions?</font> <br> <br><font size=2 face="sans-serif">Thank you,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Michael Kay" <mike@saxonica.com></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">10/18/2007 01:53 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"'John Boyer'" <xforms-issues@mn.aptest.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif"><w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.10.4 (PR#147)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> <br> Well, I'm clearly not going to persuade you, but it seems a very<br> short-sighted attitude to me.<br> <br> If the XForms specification doesn't support XPath 2.0 until 2010, then an<br> increasing number of vendors will support it unilaterally (some already do),<br> which means the coexistence and transition issues will be even worse.<br> <br> In any, case, the argument seems a bit like the millenium bug: we won't<br> worry about this problem because it will be three years before users notice<br> it.<br> <br> Michael Kay<br> <br> <br> > -----Original Message-----<br> > From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2>mailto:xforms-issues@mn.aptest.com</font></tt></a><tt><font size=2>] <br> > Sent: 18 October 2007 09:27<br> > To: mike@saxonica.com<br> > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br> > Subject: Re: 7.10.4 (PR#147)<br> > <br> > Hi Michael,<br> > <br> > I received your follow-up recommending that we add <br> > seconds-from-1970() and deprecate seconds-from-dataTime() to <br> > make future updating to XForms 2.0/XPath 2.0 easier.<br> > <br> > This only seems to add confusing complexities to XForms 1.1 <br> > in order to make at best a minor improvement to the future <br> > update capabilities. The update of 1.x content to XForms 2.0 <br> > should have much bigger issues than this.<br> > It is also by no means clear that a form author undergoing <br> > such a large update of content would even want to retain the <br> > 1970 semantic anyway because the typical call of these <br> > functions is to do date math and comparisons.<br> > <br> > Finally, it should be noted that the current estimated <br> > (optimistic) timeframe for an XForms 2.0 recommendation is <br> > the end of 2010.<br> > <br> > Best regards,<br> > John Boyer<br> > <br> > > <br> > > <br> > > L. The seconds-from-dateTime() function poses a <br> > particular problem<br> > > because XPath 2.0 offers a function with the same name and<br> > > different semantics.<br> > > <br> > > You should define whether leap second are taken into <br> > account, and<br> > > if so, specify how.<br> > > <br> > > <br> <br> <br> </font></tt> <br> --=_alternative 0036970F88257378_=--
FOLLOWUP 5:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 006DA7FF8825738E_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Could you please let us know what should be put on the final disposition of this comment? We did indicate that our function does not recognize leap seconds (in accord with XPath 2.0). Based on the use cases elaborated at the end of the discussion thread (topmost below), would you be willing to agree (however reluctantly) with the group's desire to proceed with this longstanding XForms 1.0 function for now and deal with any semantic differences with the XPath 2.0 when we transition to XPath 2.0 in XForms 2.0? Or do you want us to record a disagree result, or do you want us to record a formal objection? Thank you for your consideration. If you could please let us know by Monday, this would help as we are coming up to the transition meeting with the director and the current setting is 'No response' to the end of the thread. Best regards, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer John Boyer/CanWest/IBM@IBMCA Sent by: www-forms-editor-request@w3.org 10/18/2007 02:56 AM To "Michael Kay" <mike@saxonica.com> cc w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org, "'John Boyer'" <xforms-issues@mn.aptest.com> Subject RE: 7.10.4 (PR#147) Hi Michael, I agree that in the general case, without looking at the specific functions at hand, it might seem very short-sighted. The real question that needs an answer is whether the difference of semantic breaks the real uses cases we have for this function, which are 1) Compare two dates seconds-from-dateTime(D1) < seconds-from-dateTime(D2) 2) Difference, which can be string manipulated into a duration if needed seconds-from-dateTime(D1) - seconds-from-dateTime(D2) 3) Compute 2 hours from now adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) + 7200)) Can you let us know please if you think the difference of semantic will break one of these three expressions? Thank you, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Michael Kay" <mike@saxonica.com> Sent by: www-forms-editor-request@w3.org 10/18/2007 01:53 AM To "'John Boyer'" <xforms-issues@mn.aptest.com> cc <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> Subject RE: 7.10.4 (PR#147) Well, I'm clearly not going to persuade you, but it seems a very short-sighted attitude to me. If the XForms specification doesn't support XPath 2.0 until 2010, then an increasing number of vendors will support it unilaterally (some already do), which means the coexistence and transition issues will be even worse. In any, case, the argument seems a bit like the millenium bug: we won't worry about this problem because it will be three years before users notice it. Michael Kay > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 18 October 2007 09:27 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.10.4 (PR#147) > > Hi Michael, > > I received your follow-up recommending that we add > seconds-from-1970() and deprecate seconds-from-dataTime() to > make future updating to XForms 2.0/XPath 2.0 easier. > > This only seems to add confusing complexities to XForms 1.1 > in order to make at best a minor improvement to the future > update capabilities. The update of 1.x content to XForms 2.0 > should have much bigger issues than this. > It is also by no means clear that a form author undergoing > such a large update of content would even want to retain the > 1970 semantic anyway because the typical call of these > functions is to do date math and comparisons. > > Finally, it should be noted that the current estimated > (optimistic) timeframe for an XForms 2.0 recommendation is > the end of 2010. > > Best regards, > John Boyer > > > > > > > L. The seconds-from-dateTime() function poses a > particular problem > > because XPath 2.0 offers a function with the same name and > > different semantics. > > > > You should define whether leap second are taken into > account, and > > if so, specify how. > > > > --=_alternative 006DA7FF8825738E_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Michael, </font> <br> <br><font size=2 face="sans-serif">Could you please let us know what should be put on the final disposition of this comment?</font> <br><font size=2 face="sans-serif">We did indicate that our function does not recognize leap seconds (in accord with XPath 2.0).</font> <br><font size=2 face="sans-serif">Based on the use cases elaborated at the end of the discussion thread (topmost below), would you be willing to agree (however reluctantly) with the group's desire to proceed with this longstanding XForms 1.0 function for now and deal with any semantic differences with the XPath 2.0 when we transition to XPath 2.0 in XForms 2.0?</font> <br> <br><font size=2 face="sans-serif">Or do you want us to record a disagree result, or do you want us to record a formal objection? </font> <br> <br><font size=2 face="sans-serif">Thank you for your consideration. If you could please let us know by Monday, this would help as we are coming up to the transition meeting with the director and the current setting is 'No response' to the end of the thread.</font> <br> <br><font size=2 face="sans-serif">Best regards,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>John Boyer/CanWest/IBM@IBMCA</b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">10/18/2007 02:56 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"Michael Kay" <mike@saxonica.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif">w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org, "'John Boyer'" <xforms-issues@mn.aptest.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.10.4 (PR#147)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2 face="sans-serif"><br> Hi Michael,</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> I agree that in the general case, without looking at the specific functions at hand, it might seem very short-sighted.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> The real question that needs an answer is whether the difference of semantic breaks the real uses cases we have for this function, which are</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> 1) Compare two dates <br> seconds-from-dateTime(D1) &lt; seconds-from-dateTime(D2)</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> 2) Difference, which can be string manipulated into a duration if needed</font><font size=3> </font><font size=2 face="sans-serif"><br> seconds-from-dateTime(D1) - seconds-from-dateTime(D2)</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> 3) Compute 2 hours from now</font><font size=3> </font><font size=2 face="sans-serif"><br> adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime(now()) + 7200))</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Can you let us know please if you think the difference of semantic will break one of these three expressions?</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Thank you,</font><font size=3> </font><font size=2 face="sans-serif"><br> John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 color=blue face="sans-serif"><u>http://www.ibm.com/developerworks/blogs/page/JohnBoyer</u></font></a><font size=2 face="sans-serif"><br> </font><font size=3><br> <br> <br> </font> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Michael Kay" <mike@saxonica.com></b> <br> Sent by: www-forms-editor-request@w3.org</font><font size=3> </font> <p><font size=1 face="sans-serif">10/18/2007 01:53 AM</font><font size=3> </font> <td width=59%> <br> <table width=100%> <tr valign=top> <td width=11%> <div align=right><font size=1 face="sans-serif">To</font></div> <td width=88%><font size=1 face="sans-serif">"'John Boyer'" <xforms-issues@mn.aptest.com></font><font size=3> </font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif"><w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org></font><font size=3> </font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.10.4 (PR#147)</font></table> <br> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br><font size=3><br> <br> </font><tt><font size=2><br> <br> <br> Well, I'm clearly not going to persuade you, but it seems a very<br> short-sighted attitude to me.<br> <br> If the XForms specification doesn't support XPath 2.0 until 2010, then an<br> increasing number of vendors will support it unilaterally (some already do),<br> which means the coexistence and transition issues will be even worse.<br> <br> In any, case, the argument seems a bit like the millenium bug: we won't<br> worry about this problem because it will be three years before users notice<br> it.<br> <br> Michael Kay<br> <br> <br> > -----Original Message-----<br> > From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2 color=blue><u>mailto:xforms-issues@mn.aptest.com</u></font></tt></a><tt><font size=2>] <br> > Sent: 18 October 2007 09:27<br> > To: mike@saxonica.com<br> > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br> > Subject: Re: 7.10.4 (PR#147)<br> > <br> > Hi Michael,<br> > <br> > I received your follow-up recommending that we add <br> > seconds-from-1970() and deprecate seconds-from-dataTime() to <br> > make future updating to XForms 2.0/XPath 2.0 easier.<br> > <br> > This only seems to add confusing complexities to XForms 1.1 <br> > in order to make at best a minor improvement to the future <br> > update capabilities. The update of 1.x content to XForms 2.0 <br> > should have much bigger issues than this.<br> > It is also by no means clear that a form author undergoing <br> > such a large update of content would even want to retain the <br> > 1970 semantic anyway because the typical call of these <br> > functions is to do date math and comparisons.<br> > <br> > Finally, it should be noted that the current estimated <br> > (optimistic) timeframe for an XForms 2.0 recommendation is <br> > the end of 2010.<br> > <br> > Best regards,<br> > John Boyer<br> > <br> > > <br> > > <br> > > L. The seconds-from-dateTime() function poses a <br> > particular problem<br> > > because XPath 2.0 offers a function with the same name and<br> > > different semantics.<br> > > <br> > > You should define whether leap second are taken into <br> > account, and<br> > > if so, specify how.<br> > > <br> > > <br> <br> </font></tt><font size=3><br> </font> <br> --=_alternative 006DA7FF8825738E_=--
FOLLOWUP 6:
From: "Michael Kay" <mike@saxonica.com> I would strongly suggest that you provide a synonym for this function (perhaps seconds-since-1970())and deprecate the old name, to make transition easier in 2.0. Michael Kay > -----Original Message----- > From: Nick Van den Bleeken [mailto:xforms-issues@mn.aptest.com] > Sent: 13 September 2007 08:57 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org > Subject: Re: 7.10.4 (PR#147) > > Dear Michael, > > The seconds-from-dateTime() function 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, we will add text that states that > leap seconds are not supported. > > Regards, > > Nick Van den Bleeken > > > > > > L. The seconds-from-dateTime() function poses a > particular problem > > because XPath 2.0 offers a function with the same name and > > different semantics. > > > > You should define whether leap second are taken into > account, and > > if so, specify how. > > > >
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Michael, I received your follow-up recommending that we add seconds-from-1970() and deprecate seconds-from-dataTime() to make future updating to XForms 2.0/XPath 2.0 easier. This only seems to add confusing complexities to XForms 1.1 in order to make at best a minor improvement to the future update capabilities. The update of 1.x content to XForms 2.0 should have much bigger issues than this. It is also by no means clear that a form author undergoing such a large update of content would even want to retain the 1970 semantic anyway because the typical call of these functions is to do date math and comparisons. Finally, it should be noted that the current estimated (optimistic) timeframe for an XForms 2.0 recommendation is the end of 2010. Best regards, John Boyer > > > L. The seconds-from-dateTime() function poses a particular problem > because XPath 2.0 offers a function with the same name and > different semantics. > > You should define whether leap second are taken into account, and > if so, specify how. > >
REPLY 2:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Dear Michael, The seconds-from-dateTime() function 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, we will add text that states that leap seconds are not supported. Regards, Nick Van den Bleeken > > > L. The seconds-from-dateTime() function poses a particular problem > because XPath 2.0 offers a function with the same name and > different semantics. > > You should define whether leap second are taken into account, and > if so, specify how. > >
PROBLEM ID: 161
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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
ORIGINAL MESSAGE:
From: "Elliotte Harold" <elharo@metalab.unc.edu> Although there's an existing erratum for 7.11.1 it doesn't seem to address this problem: "An XForms Model can contain more that one instance." --> "An XForms Model can contain more than one instance." that --> than -- Elliotte Rusty Harold elharo@metalab.unc.edu Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Elliotte, Thank you. This has been handled now. Best regards, John Boyer > > Although there's an existing erratum for 7.11.1 it doesn't seem to > address this problem: > > > "An XForms Model can contain more that one instance." > > --> > > "An XForms Model can contain more than one instance." > > that --> than > > > -- > Elliotte Rusty Harold elharo@metalab.unc.edu > Java I/O 2nd Edition Just Published! > http://www.cafeaulait.org/books/javaio2/ > http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/ > >
PROBLEM ID: 66
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
we need the specify the interval of random
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-random "This function generates and returns a uniformly distributed random or pseudorandom number between 0.0 and 1.0" I assume what is meant here is 0.0<=random()<1.0
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, This is now fixed. Please see the editor's draft available from the Forms WG website. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#fn-random > > "This function generates and returns a uniformly distributed random or > pseudorandom number between 0.0 and 1.0" > > I assume what is meant here is 0.0<=random()<1.0 > > >
PROBLEM ID: 34
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: Agree
NOTES:
It is just an editorial change
ORIGINAL MESSAGE:
From: "Erik Bruchez" <ebruchez@orbeon.com> All, This is really minor but easy to fix. The wording used to specify that XForms engine processing must stop is "halt processing" ("4.5 Error Indications") or "processing halts" (everywhere else). There is one exception in section "7.12 Extension Functions" where the wording is "stop processing". I recommend fixing 7.12 by changing from "[...] and stop processing by [...]" to "[...] and processing halts by [...]". -Erik -- Orbeon Forms - Web Forms for the Enterprise Done the Right Way http://www.orbeon.com/
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Erik, You are right. We will update the spec accordingly. Many thanks. Nick Van den Bleeken For the Forms WG > > All, > > This is really minor but easy to fix. > > The wording used to specify that XForms engine processing must stop is > "halt processing" ("4.5 Error Indications") or "processing halts" > (everywhere else). > > There is one exception in section "7.12 Extension Functions" where the > wording is "stop processing". > > I recommend fixing 7.12 by changing from "[...] and stop processing by > [...]" to "[...] and processing halts by [...]". > > -Erik > > -- > Orbeon Forms - Web Forms for the Enterprise Done the Right Way > http://www.orbeon.com/ > >
PROBLEM ID: 156
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: No Response
NOTES:
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.
ORIGINAL MESSAGE:
From: aaronr@us.ibm.com Full_Name: Aaron Reed Submission from: (NULL) (32.97.110.142) Submitted by: boyerj Date: Mon, 30 Apr 2007 23:56:50 +0200 To: www-forms-editor@w3.org From: "Aaron Reed" <aaronr@us.ibm.com> 22) Section 7.2 - Shouldn't hasFeature return 1.1? Otherwise how do I know if the processor handles 1.1 stuff?
REPLY 1:
From: Nick Van den Bleeken <xforms-issues@mn.aptest.com> Hi Aaron, hasFeature returns 1.0 because it returning the version of the DOM interface and there is no new version (e.g.: 1.1) of the DOM interface in XForms 1.1. We also aren't going to add a 'getProcessorVersion()' function to the IDL because our interface doesn't contain any processor version dependent methods. Regards, Nick Van den Bleeken > Full_Name: Aaron Reed > Submission from: (NULL) (32.97.110.142) > Submitted by: boyerj > > > Date: Mon, 30 Apr 2007 23:56:50 +0200 > To: www-forms-editor@w3.org > From: "Aaron Reed" <aaronr@us.ibm.com> > > 22) Section 7.2 - Shouldn't hasFeature return 1.1? Otherwise how do I know > if the processor handles 1.1 stuff? > >
PROBLEM ID: 67
STATE: Approved and Implemented
EDIT: Substantive
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
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
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-hmac Why bother with all the alternatives for the parameter? MD5 is missing from the list.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, The alternatives have been reduced to a single keyword per hash algorithm: MD5 and SHA-1, SHA-256, SHA-384, and SHA-512. As part of that, MD5 was added (esp. since md5 was removed). Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#fn-hmac > > Why bother with all the alternatives for the parameter? > > MD5 is missing from the list. > >
PROBLEM ID: 64
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
Add example: power(2, 3) Returns 8
ORIGINAL MESSAGE:
From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> http://www.w3.org/TR/xforms11/#fn-power Please give real values in examples, not just error cases, so people can check their understanding.
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Steven, This is done. Please see the editor's draft from the Forms WG website. Thanks, John Boyer > > http://www.w3.org/TR/xforms11/#fn-power > > Please give real values in examples, not just error cases, so people > can check their understanding. > >
PROBLEM ID: 145
STATE: Approved and Implemented
EDIT: None
RESOLUTION: Reject
USER POSITION: Disagree
ORIGINAL MESSAGE:
From: "Michael Kay" <mike@saxonica.com> J. The random() function poses semantic problems because it is not a pure function. Users of this function will have expectations, for example that the function call will not be moved out of a predicate, which the XPath formal semantics cannot guarantee. Functions that depend on anything beyond their parameters don't fit the design of XPath. This is a hard area. We're quite willing to work with you on designing this. (: We note that this function is new in XForms 1.1 so there are no compatibility requirements here :)
FOLLOWUP 1:
From: "Michael Kay" <mike@saxonica.com> Thanks for the thoughtful answer. I wasn't really concerned about stability of the environment across different XPath evaluations: I was thinking of stability within a single evaluation, for example the semantics of an expression such as for $i in 1 to 20 return random() The other functions that you mention have an explicit and formalized dependency on the dynamic context, which is either invariant for the evaluation of an XPath expression, or changes in a well-defined way (as with the context item, position, and size inside a predicate). This is not the case for your proposed random() function, and I can see implementations having considerable difficulty with expressions such as the one above: essentially, optimizers will have to special-case it, which means it may not be possible to implement it without changes to the core of the XPath engine. It's possible that in future the work on XQuery scripting extensions may be able to formalize the semantics of functions that have side-effects, but I think it would be unwise to anticipate that work for the sake of one function. I think you would be better off providing a function that returns a sequence of random numbers, along the lines of exslt:random(), defined here: http://www.exslt.org/random/index.html That function was designed after informed discussion of these issues in the community. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 24 October 2007 05:52 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.8.8 (PR#145) > > Hi Michael, > > The working group recognizes that there is a bit of a backlog > of expectations about XPath, particularly in light of its use > within XSLT. Strictly speaking, there is nothing in the > XPath 1.0 recommendation to suggest that extension functions > are unable to rely on sources of information other than > explicit parameters, and of course the implicit parameter of > the data model containing the context node. > > As a result, the issue extends beyond the particular function > mentioned in your comment. The same issue exists for other > functions new to XForms 1.1 including the local-date(), > local-dateTime(), context() and event() functions, but also, > crucially, functions such as now(), instance(), index() and > property() in 1.0. > The 1.0 functions in particular have proven that XForms > processors are able to > implement functions of this type, a necessary component for > exiting CR. The > new functions in 1.1, including the one you mentioned, do not > extend the use of XPath in a fundamentally new way beyond the > XForms 1.0 recommendation. > > Perhaps of equal importance, XForms is a document format that > is capable of containing both XPath expressions that operate > over instance data and also performing mutations of the > instance data. Because a mutation can occur between > virtually any two successive XPath evaluations, it happens > that the types of optimizations you mentioned below are not > possible for XForms. Put another way, XPath functions do > indeed rely on another data source not expressed in their > parameters: the document data model. Other language > consumers of XPath may hold constant the input document data > model, so that it appears that functions are only dependent > on their parameters. But in XForms, the data must be "filled > in" by the user, so mutation of the document data model is > unavoidable. As a result, functions like id(), last(), > count(), position() and even simple name tests are subject to > change from one evaluation of a given XPath expression to the next. > > For these reasons, the working group resolved to retain the > functions defined in both XForms 1.0 and XForms 1.1. As > well, we do agree that it is necessary to have discussions > with the XQuery group to gain a better understanding of how > classic XPath optimization techniques are affected by issues > like document > mutation in XForms. In fact, one might regard our work on > dependency lists and > the master dependency digraph that drives recalculation as > examples of optimizations that might be more broadly > applicable than just to XForms. > > Thank you for your consideration of XForms. > > Best regards, > John Boyer > > > > > > > > > J. The random() function poses semantic problems > because it is not > > a pure function. Users of this function will have > expectations, for > > example that the function call will not be moved out of a > > predicate, which the XPath formal semantics cannot guarantee. > > > > Functions that depend on anything beyond their > parameters don't fit > > the design of XPath. > > > > This is a hard area. We're quite willing to work with you on > > designing this. (: We note that this function is new in > XForms 1.1 > > so there are no compatibility requirements here :) > > > > > >
FOLLOWUP 2:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 006EF9828825738E_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Could you please let us know what should be put on the final disposition of this comment? Given the additional information about the XForms perspective, which combines mutability with a batch processing view of XPaths, was convincing enough that you would be willing to accept that the function in question presents no special burden in our case, esp. in comparison to the resulting ease of authoring. Or would you prefer that we record a disagree result, or a formal objection result. Could you please let us know by Monday since the current recorded result is 'No response' to the end of the thread, but I would like a more definitive setting given the work that has gone into this consideration. Thank you, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer John Boyer/CanWest/IBM@IBMCA Sent by: www-forms-editor-request@w3.org 10/24/2007 09:21 AM To "Michael Kay" <mike@saxonica.com> cc w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org, "'John Boyer'" <xforms-issues@mn.aptest.com> Subject RE: 7.8.8 (PR#145) Hi Michael, Scripted loops in XForms live outside of the XPath expression language in XForms. Also, in XForms the form author's perspective is that when they make a script change, then all calculations are performed. The calculations are separate XPaths, but it is a little like running them in a loop whose order is determined by topological sorting. The point is that in that case, which is conceptually similar to the one you pointed out, I have personally run a form that invoked now() twice-- in two separate XPaths-- and the one second boundary was crossed between the two executions. Similarly, UI refreshment is a time when there is the potential for a lot of change at once based on event handlers for the dispatched UI events. Again, these changes affect how succeeding XPaths will run even though the full set of XPaths are viewed as a 'batch' from the author's perspective. The point is that from XForms perspective, which combines DOM mutability with 'batch' XPath processing, the particular function in question presents no additional burden of care on the form author, nor unfortunately is there any other way to introduce this required feature that would not introduce the same burden of care on the form author. Best regards, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Michael Kay" <mike@saxonica.com> Sent by: www-forms-editor-request@w3.org 10/24/2007 02:35 AM To "'John Boyer'" <xforms-issues@mn.aptest.com> cc <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> Subject RE: 7.8.8 (PR#145) Thanks for the thoughtful answer. I wasn't really concerned about stability of the environment across different XPath evaluations: I was thinking of stability within a single evaluation, for example the semantics of an expression such as for $i in 1 to 20 return random() The other functions that you mention have an explicit and formalized dependency on the dynamic context, which is either invariant for the evaluation of an XPath expression, or changes in a well-defined way (as with the context item, position, and size inside a predicate). This is not the case for your proposed random() function, and I can see implementations having considerable difficulty with expressions such as the one above: essentially, optimizers will have to special-case it, which means it may not be possible to implement it without changes to the core of the XPath engine. It's possible that in future the work on XQuery scripting extensions may be able to formalize the semantics of functions that have side-effects, but I think it would be unwise to anticipate that work for the sake of one function. I think you would be better off providing a function that returns a sequence of random numbers, along the lines of exslt:random(), defined here: http://www.exslt.org/random/index.html That function was designed after informed discussion of these issues in the community. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 24 October 2007 05:52 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.8.8 (PR#145) > > Hi Michael, > > The working group recognizes that there is a bit of a backlog > of expectations about XPath, particularly in light of its use > within XSLT. Strictly speaking, there is nothing in the > XPath 1.0 recommendation to suggest that extension functions > are unable to rely on sources of information other than > explicit parameters, and of course the implicit parameter of > the data model containing the context node. > > As a result, the issue extends beyond the particular function > mentioned in your comment. The same issue exists for other > functions new to XForms 1.1 including the local-date(), > local-dateTime(), context() and event() functions, but also, > crucially, functions such as now(), instance(), index() and > property() in 1.0. > The 1.0 functions in particular have proven that XForms > processors are able to > implement functions of this type, a necessary component for > exiting CR. The > new functions in 1.1, including the one you mentioned, do not > extend the use of XPath in a fundamentally new way beyond the > XForms 1.0 recommendation. > > Perhaps of equal importance, XForms is a document format that > is capable of containing both XPath expressions that operate > over instance data and also performing mutations of the > instance data. Because a mutation can occur between > virtually any two successive XPath evaluations, it happens > that the types of optimizations you mentioned below are not > possible for XForms. Put another way, XPath functions do > indeed rely on another data source not expressed in their > parameters: the document data model. Other language > consumers of XPath may hold constant the input document data > model, so that it appears that functions are only dependent > on their parameters. But in XForms, the data must be "filled > in" by the user, so mutation of the document data model is > unavoidable. As a result, functions like id(), last(), > count(), position() and even simple name tests are subject to > change from one evaluation of a given XPath expression to the next. > > For these reasons, the working group resolved to retain the > functions defined in both XForms 1.0 and XForms 1.1. As > well, we do agree that it is necessary to have discussions > with the XQuery group to gain a better understanding of how > classic XPath optimization techniques are affected by issues > like document > mutation in XForms. In fact, one might regard our work on > dependency lists and > the master dependency digraph that drives recalculation as > examples of optimizations that might be more broadly > applicable than just to XForms. > > Thank you for your consideration of XForms. > > Best regards, > John Boyer > > > > > > > > > J. The random() function poses semantic problems > because it is not > > a pure function. Users of this function will have > expectations, for > > example that the function call will not be moved out of a > > predicate, which the XPath formal semantics cannot guarantee. > > > > Functions that depend on anything beyond their > parameters don't fit > > the design of XPath. > > > > This is a hard area. We're quite willing to work with you on > > designing this. (: We note that this function is new in > XForms 1.1 > > so there are no compatibility requirements here :) > > > > > > --=_alternative 006EF9828825738E_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Michael,</font> <br> <br><font size=2 face="sans-serif">Could you please let us know what should be put on the final disposition of this comment?</font> <br><font size=2 face="sans-serif">Given the additional information about the XForms perspective, which combines mutability with a batch processing view of XPaths, was convincing enough that you would be willing to accept that the function in question presents no special burden in our case, esp. in comparison to the resulting ease of authoring. Or would you prefer that we record a disagree result, or a formal objection result. Could you please let us know by Monday since the current recorded result is 'No response' to the end of the thread, but I would like a more definitive setting given the work that has gone into this consideration.</font> <br> <br><font size=2 face="sans-serif">Thank you,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>John Boyer/CanWest/IBM@IBMCA</b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">10/24/2007 09:21 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"Michael Kay" <mike@saxonica.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif">w3c-xml-query-wg@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org, "'John Boyer'" <xforms-issues@mn.aptest.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.8.8 (PR#145)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2 face="sans-serif"><br> Hi Michael,</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Scripted loops in XForms live outside of the XPath expression language in XForms.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Also, in XForms the form author's perspective is that when they make a script change, then all calculations are performed. The calculations are separate XPaths, but it is a little like running them in a loop whose order is determined by topological sorting. The point is that in that case, which is conceptually similar to the one you pointed out, I have personally run a form that invoked now() twice-- in two separate XPaths-- and the one second boundary was crossed between the two executions. Similarly, UI refreshment is a time when there is the potential for a lot of change at once based on event handlers for the dispatched UI events. Again, these changes affect how succeeding XPaths will run even though the full set of XPaths are viewed as a 'batch' from the author's perspective.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> The point is that from XForms perspective, which combines DOM mutability with 'batch' XPath processing, the particular function in question presents no additional burden of care on the form author, nor unfortunately is there any other way to introduce this required feature that would not introduce the same burden of care on the form author.</font><font size=3> <br> </font><font size=2 face="sans-serif"><br> Best regards,</font><font size=3> </font><font size=2 face="sans-serif"><br> John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 color=blue face="sans-serif"><u>http://www.ibm.com/developerworks/blogs/page/JohnBoyer</u></font></a><font size=2 face="sans-serif"><br> </font><font size=3><br> <br> <br> </font> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Michael Kay" <mike@saxonica.com></b> <br> Sent by: www-forms-editor-request@w3.org</font><font size=3> </font> <p><font size=1 face="sans-serif">10/24/2007 02:35 AM</font><font size=3> </font> <td width=59%> <br> <table width=100%> <tr valign=top> <td width=11%> <div align=right><font size=1 face="sans-serif">To</font></div> <td width=88%><font size=1 face="sans-serif">"'John Boyer'" <xforms-issues@mn.aptest.com></font><font size=3> </font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif"><w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org></font><font size=3> </font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.8.8 (PR#145)</font></table> <br> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br><font size=3><br> <br> </font><tt><font size=2><br> <br> Thanks for the thoughtful answer.<br> <br> I wasn't really concerned about stability of the environment across<br> different XPath evaluations: I was thinking of stability within a single<br> evaluation, for example the semantics of an expression such as<br> <br> for $i in 1 to 20 return random()<br> <br> The other functions that you mention have an explicit and formalized<br> dependency on the dynamic context, which is either invariant for the<br> evaluation of an XPath expression, or changes in a well-defined way (as with<br> the context item, position, and size inside a predicate). This is not the<br> case for your proposed random() function, and I can see implementations<br> having considerable difficulty with expressions such as the one above:<br> essentially, optimizers will have to special-case it, which means it may not<br> be possible to implement it without changes to the core of the XPath engine.<br> <br> It's possible that in future the work on XQuery scripting extensions may be<br> able to formalize the semantics of functions that have side-effects, but I<br> think it would be unwise to anticipate that work for the sake of one<br> function.<br> <br> I think you would be better off providing a function that returns a sequence<br> of random numbers, along the lines of exslt:random(), defined here:<br> </font></tt><font size=3 color=blue><u><br> </u></font><a href=http://www.exslt.org/random/index.html><tt><font size=2 color=blue><u>http://www.exslt.org/random/index.html</u></font></tt></a><tt><font size=2><br> <br> That function was designed after informed discussion of these issues in the<br> community.<br> <br> Michael Kay</font></tt><font size=3 color=blue><u><br> </u></font><a href=http://www.saxonica.com/><tt><font size=2 color=blue><u>http://www.saxonica.com/</u></font></tt></a><tt><font size=2> <br> <br> <br> > -----Original Message-----<br> > From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2 color=blue><u>mailto:xforms-issues@mn.aptest.com</u></font></tt></a><tt><font size=2>] <br> > Sent: 24 October 2007 05:52<br> > To: mike@saxonica.com<br> > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br> > Subject: Re: 7.8.8 (PR#145)<br> > <br> > Hi Michael,<br> > <br> > The working group recognizes that there is a bit of a backlog <br> > of expectations about XPath, particularly in light of its use <br> > within XSLT. Strictly speaking, there is nothing in the <br> > XPath 1.0 recommendation to suggest that extension functions <br> > are unable to rely on sources of information other than <br> > explicit parameters, and of course the implicit parameter of <br> > the data model containing the context node.<br> > <br> > As a result, the issue extends beyond the particular function <br> > mentioned in your comment. The same issue exists for other <br> > functions new to XForms 1.1 including the local-date(), <br> > local-dateTime(), context() and event() functions, but also, <br> > crucially, functions such as now(), instance(), index() and <br> > property() in 1.0. <br> > The 1.0 functions in particular have proven that XForms <br> > processors are able to<br> > implement functions of this type, a necessary component for <br> > exiting CR. The<br> > new functions in 1.1, including the one you mentioned, do not <br> > extend the use of XPath in a fundamentally new way beyond the <br> > XForms 1.0 recommendation.<br> > <br> > Perhaps of equal importance, XForms is a document format that <br> > is capable of containing both XPath expressions that operate <br> > over instance data and also performing mutations of the <br> > instance data. Because a mutation can occur between <br> > virtually any two successive XPath evaluations, it happens <br> > that the types of optimizations you mentioned below are not <br> > possible for XForms. Put another way, XPath functions do <br> > indeed rely on another data source not expressed in their<br> > parameters: the document data model. Other language <br> > consumers of XPath may hold constant the input document data <br> > model, so that it appears that functions are only dependent <br> > on their parameters. But in XForms, the data must be "filled <br> > in" by the user, so mutation of the document data model is <br> > unavoidable. As a result, functions like id(), last(), <br> > count(), position() and even simple name tests are subject to <br> > change from one evaluation of a given XPath expression to the next.<br> > <br> > For these reasons, the working group resolved to retain the <br> > functions defined in both XForms 1.0 and XForms 1.1. As <br> > well, we do agree that it is necessary to have discussions <br> > with the XQuery group to gain a better understanding of how <br> > classic XPath optimization techniques are affected by issues <br> > like document<br> > mutation in XForms. In fact, one might regard our work on <br> > dependency lists and<br> > the master dependency digraph that drives recalculation as <br> > examples of optimizations that might be more broadly <br> > applicable than just to XForms.<br> > <br> > Thank you for your consideration of XForms.<br> > <br> > Best regards,<br> > John Boyer<br> > <br> > > <br> > > <br> > > <br> > > J. The random() function poses semantic problems <br> > because it is not<br> > > a pure function. Users of this function will have <br> > expectations, for<br> > > example that the function call will not be moved out of a<br> > > predicate, which the XPath formal semantics cannot guarantee.<br> > > <br> > > Functions that depend on anything beyond their <br> > parameters don't fit<br> > > the design of XPath.<br> > > <br> > > This is a hard area. We're quite willing to work with you on<br> > > designing this. (: We note that this function is new in <br> > XForms 1.1<br> > > so there are no compatibility requirements here :)<br> > > <br> > > <br> > > <br> <br> </font></tt><font size=3><br> </font> <br> --=_alternative 006EF9828825738E_=--
FOLLOWUP 3:
From: w3c-xml-query-wg-request@w3.org *** NOTE: *** Your message was sent from an address which is not on the list of people who are authorized to post to this mailing list. Therefore, your message has been forwarded to the list maintainer for manual processing. If you do not see your message appear on the list or in the mailing list archives within a few business days, you may wish to contact the mailing list maintainer to investigate the delay. -- W3C Postmaster http://www.w3.org/Mail/ your message follows: ---------------------------------------------------------------------------- Hi Michael, The working group recognizes that there is a bit of a backlog of expectations about XPath, particularly in light of its use within XSLT. Strictly speaking, there is nothing in the XPath 1.0 recommendation to suggest that extension functions are unable to rely on sources of information other than explicit parameters, and of course the implicit parameter of the data model containing the context node. As a result, the issue extends beyond the particular function mentioned in your comment. The same issue exists for other functions new to XForms 1.1 including the local-date(), local-dateTime(), context() and event() functions, but also, crucially, functions such as now(), instance(), index() and property() in 1.0. The 1.0 functions in particular have proven that XForms processors are able to implement functions of this type, a necessary component for exiting CR. The new functions in 1.1, including the one you mentioned, do not extend the use of XPath in a fundamentally new way beyond the XForms 1.0 recommendation. Perhaps of equal importance, XForms is a document format that is capable of containing both XPath expressions that operate over instance data and also performing mutations of the instance data. Because a mutation can occur between virtually any two successive XPath evaluations, it happens that the types of optimizations you mentioned below are not possible for XForms. Put another way, XPath functions do indeed rely on another data source not expressed in their parameters: the document data model. Other language consumers of XPath may hold constant the input document data model, so that it appears that functions are only dependent on their parameters. But in XForms, the data must be "filled in" by the user, so mutation of the document data model is unavoidable. As a result, functions like id(), last(), count(), position() and even simple name tests are subject to change from one evaluation of a given XPath expression to the next. For these reasons, the working group resolved to retain the functions defined in both XForms 1.0 and XForms 1.1. As well, we do agree that it is necessary to have discussions with the XQuery group to gain a better understanding of how classic XPath optimization techniques are affected by issues like document mutation in XForms. In fact, one might regard our work on dependency lists and the master dependency digraph that drives recalculation as examples of optimizations that might be more broadly applicable than just to XForms. Thank you for your consideration of XForms. Best regards, John Boyer > > > > J. The random() function poses semantic problems because it is not > a pure function. Users of this function will have expectations, for > example that the function call will not be moved out of a > predicate, which the XPath formal semantics cannot guarantee. > > Functions that depend on anything beyond their parameters don't fit > the design of XPath. > > This is a hard area. We're quite willing to work with you on > designing this. (: We note that this function is new in XForms 1.1 > so there are no compatibility requirements here :) > > >
FOLLOWUP 4:
From: John Boyer <boyerj@ca.ibm.com> This is a multipart message in MIME format. --=_alternative 0059EECB8825737E_= Content-Type: text/plain; charset="US-ASCII" Hi Michael, Scripted loops in XForms live outside of the XPath expression language in XForms. Also, in XForms the form author's perspective is that when they make a script change, then all calculations are performed. The calculations are separate XPaths, but it is a little like running them in a loop whose order is determined by topological sorting. The point is that in that case, which is conceptually similar to the one you pointed out, I have personally run a form that invoked now() twice-- in two separate XPaths-- and the one second boundary was crossed between the two executions. Similarly, UI refreshment is a time when there is the potential for a lot of change at once based on event handlers for the dispatched UI events. Again, these changes affect how succeeding XPaths will run even though the full set of XPaths are viewed as a 'batch' from the author's perspective. The point is that from XForms perspective, which combines DOM mutability with 'batch' XPath processing, the particular function in question presents no additional burden of care on the form author, nor unfortunately is there any other way to introduce this required feature that would not introduce the same burden of care on the form author. Best regards, John M. Boyer, Ph.D. STSM: Lotus Forms Architect and Researcher Chair, W3C Forms Working Group Workplace, Portal and Collaboration Software IBM Victoria Software Lab E-Mail: boyerj@ca.ibm.com Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer "Michael Kay" <mike@saxonica.com> Sent by: www-forms-editor-request@w3.org 10/24/2007 02:35 AM To "'John Boyer'" <xforms-issues@mn.aptest.com> cc <w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org> Subject RE: 7.8.8 (PR#145) Thanks for the thoughtful answer. I wasn't really concerned about stability of the environment across different XPath evaluations: I was thinking of stability within a single evaluation, for example the semantics of an expression such as for $i in 1 to 20 return random() The other functions that you mention have an explicit and formalized dependency on the dynamic context, which is either invariant for the evaluation of an XPath expression, or changes in a well-defined way (as with the context item, position, and size inside a predicate). This is not the case for your proposed random() function, and I can see implementations having considerable difficulty with expressions such as the one above: essentially, optimizers will have to special-case it, which means it may not be possible to implement it without changes to the core of the XPath engine. It's possible that in future the work on XQuery scripting extensions may be able to formalize the semantics of functions that have side-effects, but I think it would be unwise to anticipate that work for the sake of one function. I think you would be better off providing a function that returns a sequence of random numbers, along the lines of exslt:random(), defined here: http://www.exslt.org/random/index.html That function was designed after informed discussion of these issues in the community. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: John Boyer [mailto:xforms-issues@mn.aptest.com] > Sent: 24 October 2007 05:52 > To: mike@saxonica.com > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org > Subject: Re: 7.8.8 (PR#145) > > Hi Michael, > > The working group recognizes that there is a bit of a backlog > of expectations about XPath, particularly in light of its use > within XSLT. Strictly speaking, there is nothing in the > XPath 1.0 recommendation to suggest that extension functions > are unable to rely on sources of information other than > explicit parameters, and of course the implicit parameter of > the data model containing the context node. > > As a result, the issue extends beyond the particular function > mentioned in your comment. The same issue exists for other > functions new to XForms 1.1 including the local-date(), > local-dateTime(), context() and event() functions, but also, > crucially, functions such as now(), instance(), index() and > property() in 1.0. > The 1.0 functions in particular have proven that XForms > processors are able to > implement functions of this type, a necessary component for > exiting CR. The > new functions in 1.1, including the one you mentioned, do not > extend the use of XPath in a fundamentally new way beyond the > XForms 1.0 recommendation. > > Perhaps of equal importance, XForms is a document format that > is capable of containing both XPath expressions that operate > over instance data and also performing mutations of the > instance data. Because a mutation can occur between > virtually any two successive XPath evaluations, it happens > that the types of optimizations you mentioned below are not > possible for XForms. Put another way, XPath functions do > indeed rely on another data source not expressed in their > parameters: the document data model. Other language > consumers of XPath may hold constant the input document data > model, so that it appears that functions are only dependent > on their parameters. But in XForms, the data must be "filled > in" by the user, so mutation of the document data model is > unavoidable. As a result, functions like id(), last(), > count(), position() and even simple name tests are subject to > change from one evaluation of a given XPath expression to the next. > > For these reasons, the working group resolved to retain the > functions defined in both XForms 1.0 and XForms 1.1. As > well, we do agree that it is necessary to have discussions > with the XQuery group to gain a better understanding of how > classic XPath optimization techniques are affected by issues > like document > mutation in XForms. In fact, one might regard our work on > dependency lists and > the master dependency digraph that drives recalculation as > examples of optimizations that might be more broadly > applicable than just to XForms. > > Thank you for your consideration of XForms. > > Best regards, > John Boyer > > > > > > > > > J. The random() function poses semantic problems > because it is not > > a pure function. Users of this function will have > expectations, for > > example that the function call will not be moved out of a > > predicate, which the XPath formal semantics cannot guarantee. > > > > Functions that depend on anything beyond their > parameters don't fit > > the design of XPath. > > > > This is a hard area. We're quite willing to work with you on > > designing this. (: We note that this function is new in > XForms 1.1 > > so there are no compatibility requirements here :) > > > > > > --=_alternative 0059EECB8825737E_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">Hi Michael,</font> <br> <br><font size=2 face="sans-serif">Scripted loops in XForms live outside of the XPath expression language in XForms.</font> <br> <br><font size=2 face="sans-serif">Also, in XForms the form author's perspective is that when they make a script change, then all calculations are performed. The calculations are separate XPaths, but it is a little like running them in a loop whose order is determined by topological sorting. The point is that in that case, which is conceptually similar to the one you pointed out, I have personally run a form that invoked now() twice-- in two separate XPaths-- and the one second boundary was crossed between the two executions. Similarly, UI refreshment is a time when there is the potential for a lot of change at once based on event handlers for the dispatched UI events. Again, these changes affect how succeeding XPaths will run even though the full set of XPaths are viewed as a 'batch' from the author's perspective.</font> <br> <br><font size=2 face="sans-serif">The point is that from XForms perspective, which combines DOM mutability with 'batch' XPath processing, the particular function in question presents no additional burden of care on the form author, nor unfortunately is there any other way to introduce this required feature that would not introduce the same burden of care on the form author.</font> <br> <br><font size=2 face="sans-serif">Best regards,</font> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> STSM: Lotus Forms Architect and Researcher<br> Chair, W3C Forms Working Group<br> Workplace, Portal and Collaboration Software<br> IBM Victoria Software Lab<br> E-Mail: boyerj@ca.ibm.com <br> <br> Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br> <br> </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>"Michael Kay" <mike@saxonica.com></b> </font> <br><font size=1 face="sans-serif">Sent by: www-forms-editor-request@w3.org</font> <p><font size=1 face="sans-serif">10/24/2007 02:35 AM</font> <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td><font size=1 face="sans-serif">"'John Boyer'" <xforms-issues@mn.aptest.com></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td><font size=1 face="sans-serif"><w3c-xml-query-wg@w3.org>, <www-forms-editor@w3.org></font> <tr valign=top> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td><font size=1 face="sans-serif">RE: 7.8.8 (PR#145)</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><tt><font size=2><br> Thanks for the thoughtful answer.<br> <br> I wasn't really concerned about stability of the environment across<br> different XPath evaluations: I was thinking of stability within a single<br> evaluation, for example the semantics of an expression such as<br> <br> for $i in 1 to 20 return random()<br> <br> The other functions that you mention have an explicit and formalized<br> dependency on the dynamic context, which is either invariant for the<br> evaluation of an XPath expression, or changes in a well-defined way (as with<br> the context item, position, and size inside a predicate). This is not the<br> case for your proposed random() function, and I can see implementations<br> having considerable difficulty with expressions such as the one above:<br> essentially, optimizers will have to special-case it, which means it may not<br> be possible to implement it without changes to the core of the XPath engine.<br> <br> It's possible that in future the work on XQuery scripting extensions may be<br> able to formalize the semantics of functions that have side-effects, but I<br> think it would be unwise to anticipate that work for the sake of one<br> function.<br> <br> I think you would be better off providing a function that returns a sequence<br> of random numbers, along the lines of exslt:random(), defined here:<br> <br> </font></tt><a href=http://www.exslt.org/random/index.html><tt><font size=2>http://www.exslt.org/random/index.html</font></tt></a><tt><font size=2><br> <br> That function was designed after informed discussion of these issues in the<br> community.<br> <br> Michael Kay<br> </font></tt><a href=http://www.saxonica.com/><tt><font size=2>http://www.saxonica.com/</font></tt></a><tt><font size=2> <br> <br> <br> > -----Original Message-----<br> > From: John Boyer [</font></tt><a href="mailto:xforms-issues@mn.aptest.com"><tt><font size=2>mailto:xforms-issues@mn.aptest.com</font></tt></a><tt><font size=2>] <br> > Sent: 24 October 2007 05:52<br> > To: mike@saxonica.com<br> > Cc: w3c-xml-query-wg@w3.org; www-forms-editor@w3.org<br> > Subject: Re: 7.8.8 (PR#145)<br> > <br> > Hi Michael,<br> > <br> > The working group recognizes that there is a bit of a backlog <br> > of expectations about XPath, particularly in light of its use <br> > within XSLT. Strictly speaking, there is nothing in the <br> > XPath 1.0 recommendation to suggest that extension functions <br> > are unable to rely on sources of information other than <br> > explicit parameters, and of course the implicit parameter of <br> > the data model containing the context node.<br> > <br> > As a result, the issue extends beyond the particular function <br> > mentioned in your comment. The same issue exists for other <br> > functions new to XForms 1.1 including the local-date(), <br> > local-dateTime(), context() and event() functions, but also, <br> > crucially, functions such as now(), instance(), index() and <br> > property() in 1.0. <br> > The 1.0 functions in particular have proven that XForms <br> > processors are able to<br> > implement functions of this type, a necessary component for <br> > exiting CR. The<br> > new functions in 1.1, including the one you mentioned, do not <br> > extend the use of XPath in a fundamentally new way beyond the <br> > XForms 1.0 recommendation.<br> > <br> > Perhaps of equal importance, XForms is a document format that <br> > is capable of containing both XPath expressions that operate <br> > over instance data and also performing mutations of the <br> > instance data. Because a mutation can occur between <br> > virtually any two successive XPath evaluations, it happens <br> > that the types of optimizations you mentioned below are not <br> > possible for XForms. Put another way, XPath functions do <br> > indeed rely on another data source not expressed in their<br> > parameters: the document data model. Other language <br> > consumers of XPath may hold constant the input document data <br> > model, so that it appears that functions are only dependent <br> > on their parameters. But in XForms, the data must be "filled <br> > in" by the user, so mutation of the document data model is <br> > unavoidable. As a result, functions like id(), last(), <br> > count(), position() and even simple name tests are subject to <br> > change from one evaluation of a given XPath expression to the next.<br> > <br> > For these reasons, the working group resolved to retain the <br> > functions defined in both XForms 1.0 and XForms 1.1. As <br> > well, we do agree that it is necessary to have discussions <br> > with the XQuery group to gain a better understanding of how <br> > classic XPath optimization techniques are affected by issues <br> > like document<br> > mutation in XForms. In fact, one might regard our work on <br> > dependency lists and<br> > the master dependency digraph that drives recalculation as <br> > examples of optimizations that might be more broadly <br> > applicable than just to XForms.<br> > <br> > Thank you for your consideration of XForms.<br> > <br> > Best regards,<br> > John Boyer<br> > <br> > > <br> > > <br> > > <br> > > J. The random() function poses semantic problems <br> > because it is not<br> > > a pure function. Users of this function will have <br> > expectations, for<br> > > example that the function call will not be moved out of a<br> > > predicate, which the XPath formal semantics cannot guarantee.<br> > > <br> > > Functions that depend on anything beyond their <br> > parameters don't fit<br> > > the design of XPath.<br> > > <br> > > This is a hard area. We're quite willing to work with you on<br> > > designing this. (: We note that this function is new in <br> > XForms 1.1<br> > > so there are no compatibility requirements here :)<br> > > <br> > > <br> > > <br> <br> <br> </font></tt> <br> --=_alternative 0059EECB8825737E_=--
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Michael, The working group recognizes that there is a bit of a backlog of expectations about XPath, particularly in light of its use within XSLT. Strictly speaking, there is nothing in the XPath 1.0 recommendation to suggest that extension functions are unable to rely on sources of information other than explicit parameters, and of course the implicit parameter of the data model containing the context node. As a result, the issue extends beyond the particular function mentioned in your comment. The same issue exists for other functions new to XForms 1.1 including the local-date(), local-dateTime(), context() and event() functions, but also, crucially, functions such as now(), instance(), index() and property() in 1.0. The 1.0 functions in particular have proven that XForms processors are able to implement functions of this type, a necessary component for exiting CR. The new functions in 1.1, including the one you mentioned, do not extend the use of XPath in a fundamentally new way beyond the XForms 1.0 recommendation. Perhaps of equal importance, XForms is a document format that is capable of containing both XPath expressions that operate over instance data and also performing mutations of the instance data. Because a mutation can occur between virtually any two successive XPath evaluations, it happens that the types of optimizations you mentioned below are not possible for XForms. Put another way, XPath functions do indeed rely on another data source not expressed in their parameters: the document data model. Other language consumers of XPath may hold constant the input document data model, so that it appears that functions are only dependent on their parameters. But in XForms, the data must be "filled in" by the user, so mutation of the document data model is unavoidable. As a result, functions like id(), last(), count(), position() and even simple name tests are subject to change from one evaluation of a given XPath expression to the next. For these reasons, the working group resolved to retain the functions defined in both XForms 1.0 and XForms 1.1. As well, we do agree that it is necessary to have discussions with the XQuery group to gain a better understanding of how classic XPath optimization techniques are affected by issues like document mutation in XForms. In fact, one might regard our work on dependency lists and the master dependency digraph that drives recalculation as examples of optimizations that might be more broadly applicable than just to XForms. Thank you for your consideration of XForms. Best regards, John Boyer > > > > J. The random() function poses semantic problems because it is not > a pure function. Users of this function will have expectations, for > example that the function call will not be moved out of a > predicate, which the XPath formal semantics cannot guarantee. > > Functions that depend on anything beyond their parameters don't fit > the design of XPath. > > This is a hard area. We're quite willing to work with you on > designing this. (: We note that this function is new in XForms 1.1 > so there are no compatibility requirements here :) > > >
PROBLEM ID: 116
STATE: Approved and Implemented
EDIT: Editorial
RESOLUTION: Accept
USER POSITION: No Response
NOTES:
These were all deemed editorial. However, 22 is not so it has been moved to a separate issue.
ORIGINAL MESSAGE:
From: "Aaron Reed" <aaronr@us.ibm.com> 22) Section 7.2 - Shouldn't hasFeature return 1.1? Otherwise how do I know if the processor handles 1.1 stuff? 23) Section 7.4 - Double periods terminating the second sentence in the first paragraph. Space before the period terminating the third sentence in the first paragraph. 24) Section 7.8.5 - "The general method described in Resolving ID References in XForms is used to determine the desired run-time case object". I assume you mean repeat object? 25) Section 7.11.4 - "The node-set parameter provides nodes in one or more documents to be searched." Can you give an example of how to specify a nodeset that applies to more than one document?
REPLY 1:
From: John Boyer <xforms-issues@mn.aptest.com> Hi Aaron, Here are some responses to issues you raised in a last call email on April 30. Spec changes are available in the editor's copy of the spec available from the Forms WG website. Please let us know if you have any further concerns about these issues. Thanks, John Boyer 23) Section 7.4 - Double periods terminating the second sentence in the first paragraph. Space before the period terminating the third sentence in the first paragraph. Done. Not diff-marked. 24) Section 7.8.5 - "The general method described in Resolving ID References in XForms is used to determine the desired run-time case object". I assume you mean repeat object? Yes. Fixed. Not diff-marked. 25) Section 7.11.4 - "The node-set parameter provides nodes in one or more documents to be searched." Can you give an example of how to specify a nodeset that applies to more than one document? The document is an instance data document. Fixed. Diff-marked.