These are the collected Last Call comments on XForms 1.0 Last Call WD that were sent to the XForms mailing list (www-forms-editor@w3.org), and responses to those comments.
Status of resolution of comment:
Notification of these Last Call responses was sent to all of the commentors and the XForms list: http://lists.w3.org/Archives/Public/www-forms-editor/
Subject: Since that paragraph hasn't changed, I think it's still a problem. Please note that the suggested default processing doesn't take dependencies between instances into account.
Regards, Jérôme
addressed in our "events roundup".
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic3
Subject: http://lists.w3.org/Archives/Public/www-forms-editor/2002Jan/0002.html
Here are some remarks I had while reading the new draft:
1/ There is an inconsistence in the target of xforms:formControlInitialize
between chapters 4.2.4 and 4.2.5.
See previous thread "Target of xforms:xformControlInitialize" or
http://lists.w3.org/Archives/Public/www-forms/2001Dec/0051.html
2/ There is an inconsistence in the default processing of xforms:focus
between chapters 4.3.3 and 10.5.
See previous thread "Event xforms:focus" or
http://lists.w3.org/Archives/Public/www-forms/2002Jan/0028.html
3/ The sequence of actions in response to xforms:valueChanged is a bit
strange in chapter 4.3.6.
See previous thread "Order of xforms:revalidate and xforms:recalculate" or
http://lists.w3.org/Archives/Public/www-forms/2001Dec/0076.html
4/ There is no support of dependencies between several models (chapters
4.3.6, 4.3.17 and 10.3).
See previous threads "recalculating several models" or
http://lists.w3.org/Archives/Public/www-forms/2002Jan/0007.html and "scope of
id() (was: recalculating several models)" or
http://lists.w3.org/Archives/Public/www-forms/2002Jan/0014.html
5/ The PDF version is not up-to-date with the HTML version (at least missing parts in chapter D).
Regards, Jérôme Nègre
In summary, the changes that we have made to support multiple instances within a model adequately cover the use case described in the last call comment. see http://lists.w3.org/Archives/Member/w3c-forms/2002JulSep/0074.html
The discussion and resolution is archived at:
issue 1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic4
issue 2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic5
issue 3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic6
issue 4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic7
issue 5-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic8
Subject:
In 4.3.3, for the xforms:focus event, it says "Default processing for these events results in the following: None; notification events only."
However, 10.5 setFocus says "This action sets focus to the form control referenced by the idref attribute by dispatching an xforms:focus event."
So one says it is informational and the other says it is an action
Two solutions:
1) Two events, one to set the focus, and one to announce that focus has been set
2) Only the action event, since presumably there is no case that this action will not be honoured, and so you can listen for it for information purposes.
In this case, section 4.3 (overview of) interaction events (which is wromgly numbered, and should be numbered 4.1.3), says that focus bubbles. If it is an action event, then it should not bubble (since then focus would be set on all elements in the bubbling chain).
Steven Pemberton
addressed in our "events roundup"
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic9
Subject:
1) the binding expression in <bind> should be using the attribute
'nodeset' rather than 'ref' to be consistent with the rest of the spec.
2) (a minor one) should there be a reference to '7.3 Evaluation Context' from
'6.4.1 bind' because '7.3' deals with nested binds not mentioned in '6.4'.
- mikko
xxxxxx
The discussion and resolution is archived at:
issue
4.1-
'http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic10
issue'.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic11
Subject:
Do default namespace declarations apply to attribute _values_?
One line summary: Yes, when using a datatype based on QName from XML Schema.
Details and background: The initial question [1] was: are these referring to the same event (in attribute ev:event)?
<container
xmlns="http://container/ml"
xmlns:xforms="http://www.w3.org/2001/12/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events" >
<!-- (1) -->
<xforms:button>...
<xforms:action ev:event="xforms:activate"/>
</xforms:button>
<!-- (2) -->
<xforms:button>...
<action xmlns="http://www.w3.org/2001/12/xforms" ev:event="activate"/>
</xforms:button>
The Namespaces Recommendation [2] is silent on this--it only describes a two-part naming system (a "Qualified Name", or "QName") and how this applies to element names (default namespaces apply) and attribute names (default namespaces don't apply).
XPath [3] was one of the first Recommendations to use namespaces in attribute values. Here, default namespace declarations _do not_ have an effect on the attribute _value_. Quoting: "if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded)"
The XML Schema Recommendation [4] took this further, defining and itself using an xsd:QName datatype. It's not clear (or at least subject to debate) on how the Schema QName datatype treats unprefixed names.
This question has been answered in the document "XML Schema: Comments on Recommendation" [5]. Issue R-85 contains the following quote from Henry Thompson: "This should be clarified in the REC -- the intention is that unprefixed names are qualified iff there is a default namespace declaration in scope, i.e. as per element names, not attribute names, in XML 1.0 plus Namespaces." Note that this is contrary to the XPath approach.
The XML Events [6] specification says "To identify event types from other namespaces, qualified names, as defined in [SCHEMA], should be used." Because of the reference to Schema, event names, which occur in attributes, are treated as having any default namespace declaration in-scope for the value of the attribute.
The word "should", however, calls into question exactly what is the datatype of the 'event' attribute. Clarification of the XML Events draft (especially in the form of a Schema) would be extremely helpful, since the datatype used affects processing of that attribute.
.micah
[1] http://lists.w3.org/Archives/Member/w3c-forms/2001OctDec/0603.html
[2] http://www.w3.org/TR/REC-xml-names/#NT-QName
[3] http://www.w3.org/TR/xpath#node-tests
[4] http://www.w3.org/TR/xmlschema-2/#QName
[5] http://www.w3.org/2001/05/xmlschema-rec-comments#pfiQName
[6] http://www.w3.org/TR/xml-events/Overview.html#section-event-naming
xxxxxx
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic12
Subject:
In the last call draft of XForms 1.0, submitInfo [1] defines the characteristics of an XForms submission. Two of the attributes allowed are:
mediaTypeExtension - Optional information describing the serialization
format. This is in addition to the mediaType.
[...] mediaType - corresponds to the media-type attribute of xsl:output
The spec goes on to note:
[...] mediaTypeExtension is useful in cases where a media type alone is not sufficiently precise. For instance, a SOAP envelope would not be adequately described simply by "text/xml", additional information would be required.
Then, in the definition of xforms:submit [2]:
Selected instance data is serialized according to one of the processes defined below, as indicated by element submitInfo attributes mediaType and mediaTypeExtension. Nodes that have an associated relevant constraints that evaluates to false are not serialized.
However, the semantics of mediaTypeExtension are not defined in XForms or elsewhere. The example regarding SOAP is no longer valid, as the XMLP WG has decided [3] to use a media type that is RFC3023[4]-compliant, "application/soap+xml".
mediaTypeExtension appears to be an extensibility mechanism that was included without being fully specified, in the hopes that it will be useful in the future. While this is sometimes useful, it isn't in this case; media types have well-understood conventions for extensibilty, and it is counterproductive to introduce a new axis for typing information that isn't aligned with those already defined.
As a result, I'd suggest;
1) removing the mediaTypeExtension attribute and references to it
2) serialising any instance identified with a mediaType conforming to RFC3023 (i.e., using the '+xml' convention) as XML.
3) if it is felt that it may be necessary to allow additional XML processing that should take place before submission, this should be explicitly defined as a submission processing step, rather than piggybacking on the media type (e.g., defining an attribute that specifies an XSLT stylesheet, or one that refers to an XML processing pipeline).
Regards,
[1]
http://www.w3.org/TR/2002/WD-xforms-20020118/slice3.html#structure-model-submitInfo
[2] http://www.w3.org/TR/2002/WD-xforms-20020118/slice4.html#evt-submit
[3] http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt
[4] ftp://ftp.isi.edu/in-notes/rfc3023.txt --
Mark Nottingham http://www.mnot.net/
Resolution : The XForms WG will remove mediaTypeExtension. SPEC CHANGE.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic14
Subject: In the last call draft of XForms 1.0, submitInfo [1] defines the characteristics of an XForms submission. One of the attributes is:
method - Optional indicator as to the protocol to be used to transmit the serialized instance data. Possible values include:
method = "post" | "get" | qname-but-not-ncname : "post"
The exclusion of 'put' from this list limits the power of XForms. PUT is used to update the state of a resource with a representation; in other words, if you PUT something somewhere, you can then GET the same thing from there later. POST is less specific; its semantics are that of submitting data to a process. Allowing PUT will enable XForms that can be used to update a site's content directly, rather than being processed by a script. There is also the potential for resources which accept both PUT and POST that will not be able to fully interoperate with XForms if PUT is not supported.
For more information, see [2].
[1] http://www.w3.org/TR/2002/WD-xforms-20020118/slice3.html#structure-model-submit
[2] http://www.ietf.org/internet-drafts/draft-baker-http-resource-state-model-01.txt
Regards,
-- Mark Nottingham http://www.mnot.net/
xxxxxx
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic15
Additional threads:
Subject:
Section 3.3 Model
1) Minor editorial issue: capitalization should be "model", matching the capitalization of the element name described, as throughout the rest of the document.
2) Clarification needed: For the sentences: "Hence, model elements occur before the user interaction markup." and "The content of element model is typically not rendered."
"Hence, model elements occur before the user interaction markup." and "The content of element model is typically not rendered."
It is unclear whether these sentences are talking about XHTML+XForms or the general case of an arbitrary containing document that allows XForms elements. Further, the sentences seem to be statements or observations, not imposing any suggestion or guideline for an author of an XForms-containing document profile.
Suggest adding a section in the "Document Structure" chapter called "Containing Documents", that gives firm guidance to future XYZ+XForms document profile authors. The section should include the above sentences, recast along the following lines:
"XForms Processors may require that model elements only occur before the user interaction markup, and thus a containing document should enforce this ordering on XForms elements." and "The content of element model is typically not rendered, and thus a containing document should accept model elements at a position where they will not be rendered."
Since there are unthinkably many possible containing document types, these statements are "should" (not "must"), to allow for cases where the guideline simply can't be met.
An example of how both of these guidelines are met by placing <xforms:model> inside <html:head> might be helpful here. Thanks,
.micah
xxxxxx
The discussion and resolution is archived at:
issue 8.2- http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic18
Additional threads:
Subject: Since somebody else has brought up XForms, I'd like to point out
the following section (as discovered by Paul Prescod);
http://www.w3.org/TR/xforms/slice4.html#evt-submit
In particular, The HTTP "get" protocol is deprecated for use in form
submission. Form authors should use "post" for greater compatibility. Just
on the basis of what I can see here, that looks pretty bad, to me...
> I don't have an issue with XForms not supporting GET (though once
it's
> there, I wonder why you'd want to get rid of it), but I do have an issue
if it's deprecating GET *and* claiming to be able to replace HTML forms;
> http://lists.w3.org/Archives/Public/www-forms/2002Jan/0092.html
> The thread in which this is still being discussed is;
> http://lists.w3.org/Archives/Public/www-forms/2002Jan/thread.html#81
I see that XForms 1.0 is in last call...
http://www.w3.org/TR/2002/WD-xforms-20020118/ comments are due 22 February
2002; reviewing the archive of comments submitted to the feedback address, I
don't see this in there.
With apologies for the lateness of this comment (I should have looked at XForms long ago...), I'm afraid I must say I find this aspect of the design unacceptable, on the grounds that...
"In HTTP, anything which does not have side-effects must use GET" -- http://www.w3.org/DesignIssues/Axioms.html#state
I agree with Paul Prescod's argument in, e.g., http://lists.w3.org/Archives/Public/www-forms/2002Jan/0119.html I'm not speaking for the TAG; we haven't discussed it as a group yet.
> FWIW, I don't think this requires TAG attention yet, but if any of the TAG members are looking at XForms anyhow ...
> MB
-- Dan Connolly, W3C http://www.w3.org/People/Connolly/
We agree: GET is not deprecated (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic19
Subject: XForms should require support for PUT along with POST and GET. PUT is a legitimate way to send information to a web server. Early versions of HTTP did not have PUT but today it does.
Paul Prescod.
Agree. See message 7. (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic16
Subject: There are many examples in the spec that use the XForms XPath
functions that are missing the namespace prefix.
The namespace prefix has to be used always in XPath extension functions.
(e.g. at="cursor('cartUI') => at="xforms:cursor('cartUI')".
Incorrect examples can be found at least in sections:
'7.4.3.1 property()' : calculate="property('version')"
'7.4.2.5 cursor()' : at="cursor('cartUI')"
'9.3 repeat : Example: homogeneous coll...' 4 * cursor() '
'9.3.2 Nested Repeats' : cursor() '
-mikko
Withdrawn by author
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic25
Subject: I would just like to add my voice to those who are concerned about supporting the PUT method in XForms. This seems like a natural interaction with a DAV server, and could be particularly useful with one that also supported DeltaV since it would allow versioning of the form instance data.
I think it would be beyond the scope of the specification to define exactly how the interaction between an XForms client and a DAV server (or an HTTP server with PUT support) worked. That is already defined well enough in the HTTP and DAV specifications. The only changes I would envision for the XForms specification would be:
Section 3.6 - Add "put" as a supported method of submitInfo (the default would remain "post").
Section 4.4.1 - Reword options 4 and 5 as follows:
-------------
4. Instance data is delivered over the network using the network protocol indicated by element submitInfo attribute method.
Note: The HTTP "get" protocol is deprecated for use in form submission. Form authors should use "post" for greater compatibility, or "put" if the functionality of that method is desired and supported by the server.
5. The response returned from the submission is applied as follows: if element submitInfo attribute method has the value of "put", the entire containing document is replaced and no checking of attribute replace is done. if element submitInfo attribute replace has the value of "all", the entire containing document is replaced. If the attribute value is "instance", the response is parsed as XML and the internal instance data is replaced with the result, using the same processing as remote instance data retrieved through xlink:href, and the xforms:initialize event is dispatched to element model. Behaviors of other possible values for attribute replace are not defined in this specification.
Under no circumstances may more than a single concurrent submit process be under way for a particular XForms Model. ----------
The reason I am suggesting a restriction on the "replace" attribute when doing a PUT is simplicity. Although it may be possible to imagine a mechanism whereby a "diff" of the XML document could be generated and applied to an existing XML document, I believe that such a feature would introduce a host of complications with potential impact on the XForms spec that would not be appropriate to consider at this point. If anyone really wanted such a thing, it could be considered for a revised spec sometime in the future. However, given the lack of definition in the HTTP and DAV specifications for partial replacement of documents, I personally doubt there would ever be a need.
Thanks for considering these changes.
-- end
We are doing PUT. Please review new section to see if it satisfies. (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic17
Subject:
This is similar but I think distinct from "Re: Order of xforms:revalidate and
xforms:recalculate"... In 4.3.16 the default processing for revalidation
specifies that instance data is 'checked against any bound Xforms
Constraints'.
In 4.3.17 (recalculate) there is reference to the required and relevant
constraints forming computes for recalculation. I *infer* from this that:
- during revalidation the type and isValid constraints are 'checked'
- during recalculation the relevant, required etc constraints are 'computed'
however, I would (humbly) suggest that this is not clear from the text. Perhaps 4.3.16 & 4.3.17 should itemise the particular constraints that are to be checked during each phase of processing?
-- end
The description of the processing for the xforms-revalidate event now says: The default handling for the xforms-revalidate event must satisfy the following conditions:
1. All instance data nodes in all instance elements in the model are checked against any specified XML Schema.
2. All instance data nodes in all instance elements in the model are checked against any bound model item properties which define constraints on the value. i.e. required, constraint, minOccurs, maxOccurs.
3. The XForms Processor must dispatch the appropriate xforms-valid or xforms-invalid event to all form controls that are bound to instance data nodes in the model. "constraint" is the new name for what was "isValid"
The discussion and resolution is archived at:
Subject: Former discussion on the mailinglist lend to the introduction of
an additional conformance-level called 'Basic'.
But from my experience as an implementor of XForms it's my honest belief,
that there should be another conformance level below 'Basic' which i call
'pragmatic' as a working title.
This should only contain the features that are absolutely necessary to build
a functional form-processor ...
why should this be introduced? simply cause even a very basic (pragmatic)
implementation would help to *greatly* improve current custom
form-processing problems and open a migration path from web-forms to full
XForms.
let me describe the requirements which i consider the mimimum level:
- support of all XForms controls including group, repeat, switch. - support
for xforms:required plus support for pattern-validation (possibly via
isValid)
- support for namespaces
i think even this reduced list will be sufficient to many applications
today and even brings some additional gain to them. What basically is needed
today may be summarized under following points:
- i need defined datastructures as output of a form-session
- i need completeness of data (via required) - i like to have repeating
structures (a real pain with web-forms)
- i like to have full XML support (therefore namespace support)
- i need to validate that my sring-data conform to some pattern. This allows
to test values which otherwise need datatyping (e.g. dates)
but:
- no support for datatypes except String
- no support for Schema validation
- no support for multiple forms
- no XForms functions
- no specific event-handling (means: implementor is free to decide how to
solve this)
- no support for Xlink (load only complete containers with inline model and
instance-data)
- no requirements which need an XPath implementation
why would i like to exclude these from a 'pragmatic' conformance level?
some arguments:
- support for schema-validation and datatyping is still 'bleeding edge'; the
current available implementations are not feature-complete or cause
performance or integration problems. So, this area needs a lot of work and
testing. Requiring this in a Basic processor prevents that XForms
implementations appear quickly.
- most current systems do not need multiple forms cause they've learned to
live with the constraints of web-forms and have tailored their forms to use
only one per page (not a clean conceptual argument but a pragmatic one)
- resolving XLinks requires to implement an external interface for your
implementation which may cause a lot of effort. The same would also be
achievable by resolving this externally and putting a complete document into
the processor Thanks for considering this issue
Regards
Joern Turner
1. We appreciate your position, but we fear a proliferation of different profiles, which will especially affect interoperability and problems for authoring.
2. On the other hand we have reduced the requirements for the Basic profile, for instance not requiring XLink, but this does not reduce the requirements to the level described in your message, in particular Xpath is still required.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic26
Additional threads
Subject:
The Last Call publication of XForms 1.0 contains the schema inline as text, but not anywhere in TR space that I could find.
We should be sure to publish all the XSD files (in addition to the inline text).
Example: http://www.w3.org/TR/2002/WD-xforms-20020118/XForms-Schema.xsd
This link should work, but it doesn't.
Thanks,
.micah
Yes, the editors agree to publish standalone *.xsd files from now on.
Subject:
I'm new to this forum, but I've been addressing similar concerns within the realm of psychiatric and medical informatics via our own approach to implementing forms.
Paul Sagi's concern re privacy is especially true for forms and interviews within medicine, psychiatry, and epidemiology research. In each of these, people need to be given the opportunity to refuse to answer questions, even if they are "required" by the form or underlying data schema.
We have found that, in general, all required elements might need to support these additional options for "not answering" a question: (1) refused (e.g. for people who refuse to answer a sensitive question), (2) don't know (e.g., "do you have a family history of <rare disease X>"), (3) huh? (e.g. the person doesn't understand the question), (4) NA (e.g. if the question isn't applicable for the person, even though the programming logic suggests that it is -- an error in the logic). Survey / polling research often also needs (5) no opinion. We have associated each of these with separate comment fields so that if any of these options are selected, the user is able to optionally specify their reason for refusing, etc. In fact, the committees that oversee research often require that subjects be allowed to refuse to answer questions.
From an XForms perspective, I'm not sure how this would be addressed. XML-Schema can be used to generate <union> structures which support these additionally allowable responses for each data element, but that seems potentially burdensome upon the authors. Moreover, these exceptional answers should really have distinct user interface features from the main options (for example, we implement them as buttons to the right of each question; and the visibility of each button is determined by the privilege level of the users -- e.g. interviewer vs. interviewee). Thus, not only is this a compound data type, but it is a compound user interface element with refuse, etc. buttons whose visibility are controlled separately from the visibility of the main data element.
Can this type of functionality be supported by XForms? If not, I recommend that it be added, otherwise XForms might have limited use within medical research settings.
/Tom
The issue was responded to on www-forms
http://lists.w3.org/Archives/Public/www-forms/2002Feb/0011.html
Ask sender if the response was sufficient.
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-forms/2002Feb/0011.html
Subject:
initialization events seem ok on the whole. Here are my comments:
4.2 Initialization Events
MH: Substantive: Do we want the user to be able to <dispatch> the following events:
ModelConstruct
ModelInitialize
InitializeDone
FormControlInitialize
InitializeDone should we prevent that somehow?
4.2.1 xforms:modelConstruct MH: This seems OK.
4.2.2 xforms:modelInitialize MH: Editorial: Tense: data has been validated -> data is validated
4.2.3 xforms:initializeDone MH: Editorial: is this a notification event only? Then it should be noted.
4.2.4 xforms:UIInitialize MH: Editorial: Dispatched as part of the modelInitialize default processing.
4.2.5 xforms:formControlInitialize MH: Substantive: Target should be formControl.
-mikko
Mikko,
All your comments have been incorporated, except: 4.2 Initialization Events
MH: Substantive: Do we want the user to be able to <dispatch> the following events:
ModelConstruct
ModelInitialize
InitializeDone
FormControlInitialize
InitializeDone
should we prevent that somehow? Which I can't answer. Looks like a question for the entire group. For now, I'm marking an <issue> in the spec to make sure it doesn't get overlooked. I hope this is sufficient to resolve your Last Call request.
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-forms-editor/2002Apr/0031.html
Subject:
4.3 Interaction Events
4.3.1 DOM Mutation Events
MH: Editorial: Not all DOM mutation events bubble. Change: Bubbles: Varies
(see DOM events)
4.3.2 xforms:next and xforms:previous
MH: Substantive: Default processing should happen only at the target. These
events should not bubble, otherwise the default processing will be done both
in the control and e.g. in the enclosing group element.
4.3.3 xforms:focus and xforms:blur
MH: Substantive:
-As discussed, focus event should not bubble.
-Default processing: Set focus to the target control
-Questions: What does blur’s default processing do? Which control will have
focus after blur? What are the semantics in HTMLs blur event?
-We could use DOMfocusin DOMfocusout for notification purposes
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents
4.3.4 xforms:activate
MH: Question: Why dont we use DOMActivate? The semantics seem the same
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-eventgroupings-uievents
4.3.5 xforms:valueChanging
MH: Question:What is the use for this event? It seems useless for the user,
since there is no possibility to read the value before it is changed to the
instance. Maybe its an system internal event?
4.3.6 xforms:valueChanged
MH: Question: what happens if the user cancels the event? What will be the
value in the control & in instance? Editorial: Tense: Event XXX has been
dispatched -> Event XXX is dispatched
4.3.7 xforms:scrollFirst
MH: This seems ok
4.3.8 xforms:scrollLast
MH: This seems ok.
4.3.9 xforms:insert and xforms:delete
MH: Substantive: What is the difference between DOM mutation events and
these? I think we could just use DOMNodeInserted and DOMNodeRemoved instead
of these.
4.3.10 xforms:select and xforms:deselect MH: These seem ok as notification events
4.3.11 xforms:help and xforms:hint
MH : Substantive: I think these could be action events, so that the user
could dispatch this to a form control and make it show its help or hint? Then
it should have: Bubbles: No (Other option: it bubbles, and the first handler
stops propagation.) Default Processing: The UA should invoke the help or hint
message connected to the target Form Control.
4.3.12 xforms:alert
MH: Substantive: Default processing should happen only at the target. This
should not bubble. Other option: it bubbles, and the first handler stops
propagation.
4.3.13 xforms:valid
MH: Seems ok as a notification event.
4.3.14 xforms:invalid
MH: Substantive: Default processing should happen only at the target. This
should not bubble.
4.3.15 xforms:refresh
MH: Substantive: Default processing should happen only at the target. This
should not bubble. Note: In X-Smiles all instance changes are automatically
updated to the form controls, so this event is not needed.
4.3.16 xforms:revalidate
MH: Substantive: This is an event with default processing only at its target,
so it should not bubble Note: In some implementations, this event may be
useless. E.g. In X-Smiles, all value changes in the instance are immediately
revalidated
4.3.17 xforms:recalculate
MH: Substantive: This is an event with default processing only at its target,
so it should not bubble In some implementations, this event may be useless.
E.g. In X-Smiles, all value changes in the instance result in immediate
recalculation
4.3.18 xforms:reset MH: Substantive: This is an event with default processing only at its target, so it should not bubble -mikko
-mikko
All your comments have been incorporated, with the following notes:
* In a few places, you ask 'is this the same as the DOM event XX?'
The general answer is no, since we don't require a DOM implementation to be present. We have been given clearance to create all new events. That's also why we have the xforms prefix on all the events.
* Regarding events xforms-refresh, xforms-revalidate, and xforms-recalculate, you comment that your implementation always keeps the everything refreshed, revalidated, and recalculated, making these events unnecessary.
These events are needed because they actually define what it means to refresh, etc.
Also at one point, we intended to make it possible to limit the amount of refreshing, recalculating, etc. done on small devices by listening for these events and stopping them from reaching. (We probably need to make the XForms
Actions <refresh>, etc. do their job without sending an event for this to work, however)
I hope this is sufficient to resolve your Last Call request.
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-forms-editor/2002Apr/0029.html
Subject:
4.4 XForms Submit
4.4.1 xforms:submit
MH: Substantive: This is an event with default processing only at its target,
so it should not bubble
4.5 Error Indications
MH: Question: What does the following sentence in Error events mean in terms
of default processing and bubbling?: “Default error handling may be used”.
4.5.1 xforms:schemaConstraintsError
MH: Seems ok
4.5.2 xforms:traversalError
MH: Seems ok
4.5.3 xforms:invalidDatatypeError
MH: Seems ok
-mikko
Mikko,
This message from you had two comments:
4.4.1 xforms:submit MH: Substantive: This is an event with default processing only at its target, so it should not bubble
4.5 Error Indications
MH: Question: What does the following sentence in Error events > mean in
terms > of default processing and bubbling?: "Default error handling may
be used".
On 4.4.1, I believe we agreed that bubbling is OK. (If not, please let me know!)
On 4.5, it means that the processor may provide a default handler (log errors, etc.)
I hope this is sufficient to resolve your Last Call request.
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-forms-editor/2002Apr/0030.html
Subject:
I believe there is a typo in the last part of the example of Section 2.3.
At the end of the section, the example instance data submitted shows the
<as> value "Credit" when it should be "credit" (lowercase "c"). Here is
the example as it currently appears in the 1/18 Draft:
<instanceData>
<as>Credit</as>
<cc>1235467789012345</cc>
<exp>2001-08</exp>
</instanceData>
The correct instance data should be
<instanceData>
<as>credit</as>
<cc>1235467789012345</cc>
<exp>2001-08</exp>
</instanceData>
Thanks, Baron
Editorial issue fixed.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic27
Subject:
Regarding http://www.w3.org/TR/2002/WD-xforms-20020118/slice11.html#conform-levels-basic
The section
11.2.1 includes the following text: --------------
11.2.1 Conforming XForms Processors
· All XForms Processors must support the required portions of the
specifications normatively listed as references
(· B References).
· XForms Basic Processors must implement all required features labeled
Basic.
· XForms Full Processors must implement all required features.
-----------------
But the normative references have features labeled "Basic" (or "required" for
that matter).
John.
We agree that XForms Full vs. Basic need to be better described, and we are revising the conformance section.
The discussion and resolution is archived at:
Additional threads:
Subject:
Beyond signature controls, others have expressed the desire to incorporate other form controls, tree controls for instance, into XForms. Other groups, such as VoiceXML, also wish to build specific solutions from the general framework of XForms. There's a need to express form controls outside of the core set defined in XForms 1.0.
Note that (X)HTML allows the <object> tag as a data-submitting form control. This has been rarely used, but the limited data representation of HTML form data no doubt contributed to that.
The spec is not clear on 1) whether foreign form controls are currently allowed, and 2) if they are, what processing (if any) is applies.
The spec does clearly state:
"Note that except where specifically allowed by the Schema for XForms, foreign-namespaced elements are not allowed as content of elements in the XForms namespace."
Form control elements, however, can exist as content of the containing document, not necessarily of an XForms element
<html:body>
<xforms:input.../>
<otherns:treecontrol../> ? ...
and thus are not covered by the above statement.
To fix this, the XForms spec should be changed in one of the following ways:
1) Clearly state that foreign form controls are not allowed.
2) Clearly state that foreign form controls are allowed (and make sure ##other is in the content models of <group>, <case>, <repeat>, etc..) and specify concrete processing. [note that the processing may very well be quite minimal, as is <object> processing in HTML forms]
Given the opening paragraph, I would strongly favor the 2nd option. :-)
Thanks,
.micah
Foreign form controls are a responsibility of the host language, and therefore are not prohibited by XForms. (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic28
Subject:
<xforms:upload> control in Jan 2002 Last call spec does not save the file's mime type or filename into the instance, so those parameters are not submitted to the server. Encodings hexBin / base64 do not by themselves include mime type / filename.
A use case: an e-mail input form, where you can attach files. The user can upload any type of file. The server/person receiving the mail cannot know the type / name of the file.
Even if the upload control has the restriction <upload mediaType="image/*"/>, the receiver would still not know whether it is a png, gif, jpeg or tiff.
-------- Proposed solution:
Add two optional child elements to 'upload' element: 'mediaType' and 'fileName'. These would have single node binding.
An example:
<upload ref="attachment">
<mediaType ref="@mediatype"/>
<fileName ref="@filename"/>
</upload>
this would result in the following instance:
<xforms:instance>
<attachment mediatype="image/png"
filename="xforms.png">asodjfaosldjf
</attachment>
</xforms:instance>
-mikko
xxxxxx
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic32
Subject: Forwarded from the HTML WG: In order to comply with XHTML Modularization, abstract module definitions (for full and basic) need to be included.
Steven Pemberton (for HTML WG)
Accepted. (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic33
Subject:
These are not formal comments from the HTML Working Group, just comments from one document editor to another:
1- The PDF version of the document does not seem to be well formatted - lines overlap, and the look and feel is not nearly the same as the HTML version when it is viewed in a browser. In the XHTML specs we use html2ps with various options that seems to do a pretty good job. I would be happy to assist with that if there is interest.
2- The document is written in HTML 4.01 transitional instead of XHTML. I request that you convert it to XHTML 1.1 (if possible), or at the very least to XHTML 1.0 Transitional.
3- There is no DTD implementation. There really should be. The HTML Working Group is available to assist with defining XForms DTDs that fit with XHTML Modularization's DTDs.
4- There is no PostScript version of the document.
5- There is no "tar" version of the document archive, only zip.
6- I REALLY like your diff-mark presentation conventions, and am going to adopt them in XHTML.
Thanks!
Shane
Thank you for your editorial suggestions. Most of what you comment on is an artifact of the production process.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic34
Subject:
Can we clarify in the draft how <group>, and perhaps <repeat> are to interact with model item constraints. For example, if instance node X has relevent="false" and a group binds to node X, is the group as a whole not visible, even if child nodes of X are relevent="true"? I would expect groups bound to instance nodes to work exactly as regular controls, so that the group as a whole would be invisible.
The same question applies to <repeat> processing. If a node in the nodeset is relevent="false", should repeat processing skip that node?
-Ray
We have clarified this. It is not how you describe, but we agree the clarification was needed. Please see the relevant sections. (See Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic52
Subject:
XHTML still includes the style attribute on all elements if the Style Attribute module is used. Xforms UI Controls only allow the class attribute, but not the inline style attribute. This seems to make XHTML + Xforms different than other embeddings like XHTML + SVG where the style attribute is allowed. It may confuse authors who are used to being able to use the style attribute on all UI elements, except those in the XForms UI.
-Ray
Lack of 'style' attribute is by design -- host language may re-introduce
Subject:
In chapter 8.11.3, it is stated that the available choices are determined at run-time.
Does it mean that these choices can be changed after initialization?
If so, if the value of a selected itemset is changed, what should happen ?
If it's a closed selection, I suppose the instance data bound to the control
should be changed accordingly. If it's an open selection, should the
behaviour be the same, or should the old itemset value become the new "free
entry" text ?
Thanks,
Jérôme
We agree that this needs clarification. Please see the relevant section. (The itemset is resolved on every UI refresh; see Copenhagen FtF minutes)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic35
Subject:
I guess this may seem the ultimate in dumb questions but I think the WD could be significantly clearer on this point.
Chapter 1.1 includes the following text: "a new platform-independent markup language for online interaction between an XForms Processor and a remote user agent"
The question arises from the conjuntion of the phrases "online" interaction and "remote" user agent in association with the term "XForms Processor".
I guess the question boils down to this - Must an XForms Processor be client side? If so, why the reference to "online" interaction with the "remote" user agent?
Also, for practical purposes, isn't the XForms processor part of the "user agent"?
Andrew Watt
We agree that clarification is needed. The introductory text isn't normative, nor is it intended to be an exhaustive description of all possible XForms implementations. We do expect server-side implementations, as will become clearer as we go through a request for implementations. The text in section 1.1 has been revised.
The discussion and resolution is archived at:
Subject:
I was wondering if the XForms WG have in mind to produce a publicly available list of XForms implementations with a grid which shows what part(s) of XForms has been implemented by which implementation.
The page at http://www.w3.org/MarkUp/Forms/ refers to several "Implementations" but one of those "implementations" seems to be a request only to Mozilla to support XForms and another seems to be a promise of support at some future date. And for others it is far from clear what has actually been implemented.
A grid with clear indications of what has been *actually* been implemented by which processor at a particular date is substantially more useful to XForms authors and likely XForms authors.
I apologise for dumping (yet more) work on you guys but a list like that is a significant help to newcomers and can be expected to assist pickup of XForms.
The SVG page is at http://www.w3.org/Graphics/SVG/Test/BE-ImpStatus-20011026.html
Since the XForms WG seem to envisage jumping direct from Last Call WD to Proposed Recommendation the kind of page which I suggest would be a useful reality check as well as useful to potential XForms authors as to what is *actually* possible at any particular date.
Andrew Watt
Yes, we are planning an implementation report during CR.
Subject:
I would like to suggest that some attention be given to improving integration between the Abstract and Chapter 2.1. This relates slightly to an issue I raised, in relation to the previous Working Draft.
The Abstract refers to data model / instance data / user interface.
Chapter 2.1 refers to Purpose / Presentation / Data.
Since both these parts are intended to be introductory I suggest that clarity and coherence is highly desirable.
I am unclear how closely these two presentations are supposed to match. I assume that "user interface" and "Presentation" map one to one but what about the others?
It remains unclear to me what purpose (sorry for the pun) the Purpose heading serves. The purpose of "Purpose" is, in my view, uniformly "data collection" and the "Data" head provides the answer to the question "What data are we collecting this time?". I am still of the view that the "Purpose" heading is largely redundant and has, if anything, a slightly negative effect on clarity.
Andrew Watt
Agree.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic36
Subject:
In Chapter 2.1 "External Schema Augmentation" heading, insert "to" between "author" and "go"
In Chapter 2.4, Line 2 insert "data" after "instance".
In Chapter 2.4, first bullet point it is claimed that there is "complete flexibility" re structure of XML. But isn't it true that XForms is XML and, for example, an xforms:instance element must be nested within an xforms:model element?
I guess what you intended to say is that "There is complete flexibility in the structure of the XML constituting the instance data".
Chapter 2.5, Line 3 - Reference is made to "unstructured" script code. I think you mean something else. Script code that isn't "structured" doesn't work. Perhaps review for a more appropriate adjective?
Chapter 2.6, end of Line 3 - After "id", insert "attribute".
Chapter 2.6, Para 2, Line 1 - Replace "the" before "model" with "which".
Andrew Watt
Editorial issues fixed.
Subject:
The first paragraph in Chapter 3.1 needs to be reworded, in my view.
It is claimed "The XForms specification is an application of XML ...". In my view it would be better phrased as "XForms is an application of XML ..." or "The XForms language is an application of XML ....".
As a matter of fact the XForms specification is an application of English, not XML. :)
At the end of Line 2 replace "this specification" with "XForms".
Andrew Watt
Editorial issues fixed.
Subject:
In line 2 I think "xsd:idref" should be "xsd:IDREF".
Andrew Watt
Editorial issues fixed.
Subject:
3.3, "Instance" heading - Does an instance "document" actually exist?
3.3 "Action" heading - mention is made of "node" model but the concept of nodes (other than indirectly through the XPath 1.0) hasn't, so far as I recall in the document up to that point.
3.5 line 1 - Replace "defining" with "constraining"
3.6 In the first code snippet the standalone attribute is stated to be xsd:boolean. In other XML languages the permitted values of standalone are "yes" or "no". The permitted values of xsd:boolean as I recall are "true" and "false" which isn't quite the same.
3.6 Final Paragraph - This should be clarified. What situation are you referring to? The presence of an xlink:href attribute and an xlink:type with value of "none"? If so, is the behaviour mentioned in the paragraph consistent with XLink in that situation? Or if some other situation is being referred to then the paragraph could usefully be made clearer.
Andrew Watt
Editorial issues fixed.
Subject:
I suggest that the xsl indicative namespace prefix be included, with a suitable reference to XSLT 1.0 since the xsl prefix is used later in the specification.
I suggest that the reference to XSLT be explicitly to XSLT 1.0 since XSLT 2.0 is likely to be around during much of the life of XForms 1.0.
Andrew Watt
Editorial issues fixed.
(Note: We don't use the xsl: prefix in the spec)
Subject:
In the initial three bullet points I suggest you standardise either on lower case or upper case as the initial letter of the text of the bullet point.
4.3.5, fourth last line - Insert "to" between "expected" and "optimize"
4.4.1, numbered item 3. - The phrase "Nodes that have an associated ...". Delete "an" or change rest of sentence to singular.
4.4.4, numbered item 1 - Reference is made to XPath but the link is to XSLT. Please review for consistency.
4.4.4, numbered item 2, line 2 - Replace "an" with "and"
4.4.4.1 Replace "xform:" with "xforms:"
Andrew Watt
Editorial issues fixed.
Subject:
5.1, lines 2 and 3 - Decide if it is "basic" or "Basic"
6.1.2, Legal Values - Replace "boolean" with "xsd:boolean" for consistency
6.1.3, Legal Values - as for 6.1.2
6.1.6, Legal Values - as above
6.2.1, final two lines - Insert "to" between "author" and "extend"
6.3.4, line 1 - Insert "XML" before "Schema"
Andrew Watt
Editorial issues fixed.
Subject:
In 7.2 reference is made to instance data as an "internal structure" addressable by XPath. Then reference is made to elements and attributes. More correctly this latter should refer to element nodes and attributes nodes, since XPath operates on nodes not on elements or attributes.
7.1 and 7.3 - In the former we have "Binding expression" and in the latter "binding expression". Suggest consistency of case of initial letter.
7.3 - The expression /level1/level2/level3/@attr is not a legal XPath expression
7.4.2.2 line 2 - "node-set" rather than "node set"
7.4.2.3 - And again
7.4.2.5 - the formatting of the example code needs to be tidied
7.4.3.1 - And again
Andrew Watt
Editorial issues fixed.
Subject:
8.4 - The figure needs to be adjusted so that all of it displays correctly.
8.6 - It seems to me that there is a fundamental flaw in expression about "range". I think it is inconsistent to term a range as "continuous" when it has a stepSize attribute. Once a step size is defined the range is not continuous, in my view.
8.9 The inappropriate use of checkboxes for selectOne has reappeared. This is, in my view, an inappropriate user interface to express the notion of "select one". My recollection is that this was discussed on the list and generally agreed as undesirable/inappropriate. The behaviour described in 8.9 is NOT that of a checkbox.
8.10 - the option for a value of "radio" for selectMany should be deleted. Why provide something so intrinsically confusing for the user interface? Again, I thought it had been agreed that this was inappropriate and would be removed.
8.12.3, 2nd last line - Should there be "IDREF" twice instead of "idref"?
8.12.4, 2nd bullet point - The word caption should be in monospace, I think
8.12.4.1,
Andrew Watt
Editorial issues fixed.
* we will revisit all illustrations in that chapter
* selectOne/radio and selectMany/checkbox -- we are making specific changes
Subject:
The W3C i18n WG reviewd the XForms 1.0 Last Call draft at its latest FTF meeting (minutes at http://www.w3.org/International/Group/2002/01/ftf16/minutes#review-xforms, W3C member-only) and at its latest telcon (minutes not yet available) and wishes to provide the following feedback.
1) On the application/x-www-form-urlencoded submission method
This form submission method has no means of providing required charset information to the receiver. As a result, it is very harmful to i18n concerns and has plagued the Web for too long.
The i18n WG requests, in order of preference:
a) Remove 4.4.2 entirely (strongly preferred)
b) Move 4.4.2 to an appendix
c) Move 4.4.2 after the other 2 serialization methods
If 4.4.2 is not removed, make the note about this method being deprecated be normative (not a note) and move it to the start of the section.
If 4.4.2 is not removed, then "issue-utf8-encoding" should be resolved by mandating UTF-8 as the only permissible character encoding.
2) On the multipart/form-data submission method
This method does have a way of conveying charset information, but the XForms draft is silent about it.
The i18n WG requests that the mechanism for indicating character encoding (Content-Type header on each part with charset parameter) be mandated and shown in the examples.
Furthermore, this method suffers from the problem that the 'name' MIME parameter, used here to contain XPath expressions and therefore XML names, can only contain ASCII characters unless the value is encoded by the (fairly complex and error-prone) method of RFC 2049.
The i18n WG requests that this limitation be spelled out, that the capability to use the RFC 2049 method be mandated for both XForms producers and consumers using multipart/form-data submission and that the example in this section show at least one such 2049-encoded name parameter.
3) On the text/xml submission method
Note: there is a mistake in the first step, which specifies "XPath [XSLT]". Choose one!
Although this submission method is very good, the choice of "text/xml" as the media type is unwise, because the default character encoding for this type is specified (RFC 3023) to be US-ASCII, irrespective of any encoding declaration in the entity itself. RFC 3023 says:
"Conformant with [RFC2046], if a text/xml entity is received with the charset parameter omitted, MIME processors and XML processors MUST use the default charset value of "us-ascii"[ASCII]."
The i18n WG requests that the media type be application/xml or perhaps a new type such as application/xforms+xml, instead of text/xml. A less preferred alternative would be to stay with text/xml but mandate the use of the charset parameter in the HTTP header of the POST submission.
Note that despite long-standing obligations from the relevant specs, HTTP transactions have always very poorly indicated charset, if at all.
4) General
Please make examples better internationalized (for instance change "First name" to "Given name").
Please include an example showing that the same model can be used with different user interfaces in different languages (fields laid out in different order, fields that appear in a certain language version of the form but not in some other, e.g. "state/province", labels in different language than content).
Regards,
-- François Yergeau for the i18n WG
Point 1: we're doing c) namely moving to the end of the submission methods (now 11.7). We have mandated UTF8 encoding. We have not deprecated these methods.
Point 2. Agree, but solved in a different way (spec change)
Point 3. Agree.
Point 4. Agree.
The discussion and resolution is archived at:
issue 41.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic20
issue 41.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic22
issue 41.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic23
issue 41.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic24
issue 41.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic137
issue 41.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic138
issue 41.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic139
issue 41.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic140
Subject:
Hi,
in the last WD, the attributeGroup commonUIAttributes is defined as :
<xsd:attributeGroup name="commonUIAttributes">
<xsd:attribute ref="xml:lang" type="xsd:language" use="optional"/> ...
</xsd:attributeGroup>
But according to XML Schema Part 1 - §3.2.3, I think this should rather be :
<xsd:attributeGroup name="commonUIAttributes">
<xsd:attribute ref="xml:lang" use="optional"/> ...
</xsd:attributeGroup>
extract :
3.2.3 Constraints on XML Representations of Attribute Declarations Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on <attribute> element information items by the schema for schemas, all of the following must be true:
1 - default and fixed must not both be present.
2 - If default and use are both present, use must have the ·actual value· optional.
3 - If the item's parent is not <schema>, then all of the following must be true:
3.1- One of ref or name must be present, but not both.
3.2 - If ref is present, then all of <simpleType>, form and type must be absent.
<----------------- it's here
4 - type and <simpleType> must not both be present.
5 - The corresponding attribute declaration must satisfy the conditions set out in Constraints on Attribute Declaration Schema Components (§3.2.6).
Jérôme
Editorial issues fixed.
Subject:
The XForms 1.0 last-call draft requires that the binary data be transmitted in, at best, base64, and that it be inside the XML instance.
One of my proposed applications of XForms requires the transmission of XML instance data and large amounts of binary data gathered by an <upload> control. The data in my application, and I suspect in other voice, video, and image applications as well, will be tens of megabytes, whereas the remainder of the instance data will be small (a few thousand bytes at most).
Having the binary data embedded in the XML instance data makes the data harder to process and validate, because of the storage requirements, and restricts the range of XML processing packages I can use to implement my application.
The XForms 1.0 last-call draft allows the legacy POST of multipart/form data as in XHTML 4.01 and XHTML 1.1 forms with <input type="file"... >. Although this meets requirement to move binary data out of the XML instance, the mechanism is deprecated in XForms 1.0 last call, and furthermore does not provide XML instance data.
Therefore, I propose a mechanism for allowing the separation of the large binary data from the XML instance, namely allowing XForms model to specify by type that the XForms Processor refer to the <upload> data by URI instead of base64 or hex encoding.
An XForms Processor may choose to provide this URI by generating it locally and offering a service such as HTTP to serve up the content, or it may choose to use <submitInfo mediaType="multipart/related"> and send the content along with the text/xml instance data according to RFCS 2387, 2111, and 2557 ([1] [2] [3] [4] [5]) or it may choose some other method of generating the URI.
This proposal does not encompass such methods; it proposes changes to the XForms specification so that an interoperable implementation of large binary data form submission can be developed, and is independent of any implementation of generation or interpretation of the URI. I note that the xsd:base64Binary and xsd:hexBinary restriction on upload is not enforced in the XForms Schema, so no changes are necessary in the XForms Schema. ===============================================================
Proposed Changes
1. Section 8.5 "upload"
I propose that section 8.5 be changed to say the following:
Data Binding Restrictions: This form control can only be bound to datatypes
xsd:base64Binary, xsd:hexBinary, or xsd:anyURI, or types derived by
restriction from these.
2. Section 4.4.4.1 "Binary Content"
I propose that section 4.4.1 be changed to add the following:
Instance data nodes with values of the type xsd:anyURI are allowed, but the
mapping of URI to binary content resource is not specified here.
===============================================================
Examples
please refer to http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0061.html
(See also message 47)
The discussion and resolution is archived at:
Resolved: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic53
Accepted: http://lists.w3.org/Archives/Public/www-forms-editor/2002Jul/0055.html
Subject:
As agreed to at the last WG telecon,
Add to section 4.3 "Interaction Events", the following events
xforms:relevant
xforms:irrelevant
xforms:required
xforms:notrequired
xforms:readonly
xforms:notreadonly
Comments are in [] by me (Ray)
[Issue: are these the right names? Or should they be something like xforms:relevantChanged] [Issue: do we need notification events for minOccurs/maxOccurs? To be complete, we should, but what should be call them?]
These events are dispatched only when there is a change to the underlying model-item-constraint. All events are similar to xforms:valid Target: form control [Comment: because form controls are what are effected by the change] Bubbles: yes
[Comment: because someone might wish to write a global event handler] Cancelable: no [Comment: not sure why xforms:valid says it is not cancelable] Context Info: none Default Processing: none, notification event only
[Comment: if CSS WG adopts pseudo-classes for these UI states, and if the CSS DOM had fields to specify where something was relevent, required, etc then in the future, the default processing might say something like "set the pseudo-class field X to true/false" to reflect the event into the underlying UI state. For now, there is no default processing and it is assumed that UI control state updated by an implementation specific mechanism]]
[Issue: Should we clarify the xforms:recalculate and xforms:refresh sections of the spec to say that recalculate updates dirty bits on model item properties and xforms:refresh picks these up and issues the appropriate notification events? Or should we say they are issued directly from the recalculate handler? Or, should we just leave it up to the implementation the exact sequence in which the events are generated?]
-Ray
Ray,
The additional events you described in your message have been added to XForms. The specific names used are still subject to discussion by the group. For now, I used the names from the CSS pseudo-classes in the XHTML+XForms Profile document.
Thanks, .micah
The discussion and resolution is archived at:
http://lists.w3.org/Archives/Public/www-forms-editor/2002Apr/0028.html
Subject:
superceeded by
http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0068.html:
Replaced by message 48
The discussion and resolution is archived at:
Subject:
Dear MD,
Not to be a smart ass, but your rant about XForms being a word with no singular form contains some incorrect statements, including: scissors- a scissor is a single blade of a pair of scissors, or a more antiquated term for a single pair of scissors. cattle-the singular of cattle is cow, bull, or steer, depending on the sex of the animal and the condition of its reproductive organs.
These definitions are courtesy of Mirriam-Webster's Collegiate Dictionary. Also, I see no good reason why "XForm" is an innappropriate term. What do you suggest we call one, an XForms form?
Thanks, Dan Culley
This is about our public page, not the spec per se. No spec change requested.
Subject:
Note that in my previous message,
[1] Methods For Sending Out of Band Binary with XForms (http://lists.w3.org/Archives/Member/w3c-forms/2000OctDec/att-0067)
And
[2] SOAP Messages with Attachments (http://static.userland.com/weblogsCom/gems/soapweblogscom/soapMessagesWithAttachments.html)
have been superseded by http://www.w3.org/TR/SOAP-attachments .
In particular I draw attention to the HTTP example at http://www.w3.org/TR/SOAP-attachments#HTTPBinding with an example showing an HTTP POST including an XML body and two attachments that constitutes an automobile insurance claim. The XML body is transmitted as a text/xml document containing the claim data, and is transmitted along with a facsimile image of the signed claim form (claim.tiff) and a digital photo of the damaged car (car.jpeg).
--end
See message 43
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic54
Rejected: http://lists.w3.org/Archives/Public/www-forms-editor/2002Jul/0055.html
Subject:
Hello.
I was pointed here by Micah Dubinko to propound here my suggestions. Here they are:
1) In the standard, there are several things that need a cleaner explanation.
2) I suggest to rename the attribute "ref" on xforms:bind elements to "nodeset".
3) I suggest to allow the "readOnly" attribute on form controls.
4) I suggest that the "ref" attribute on xforms:output element be an arbitrary XPath expression, not necessarily returning a node, but also a string or number would be allowed.
5) I suggest to introduce a grouping element for "xforms:bind"s in "xforms:model"s.
6) I suggest to allow more than one xforms:instance element in one xforms:model.
7) I suggest to allow any kind of children for xforms:item.
8) I suggest the xforms:insert doesn't clone the last node in the nodeset collection, but clones a template instead.
I've met with various problems during my attempts of using the XForms for advanced forms creation. And I found that I'm currently unable to solve them (effectively, or at all) without extending the XForms namespace with my own elements/attributes, or even without modifying the XForms elements' behaviour. It is not important to me that the problems I'm mentionning will be solved the way I suggest, but that the problems will be reflected and XForms will provide means to solve them somehow (elegantly).
I appreciate the work you all have done concerning XForms. I'm sorry I have to say that, but it seems to me, that the XForms specification still needs many important things to be solved, without which a serious XForms usage would be unimaginable. In my opinion, it is too early for the specification to become a standard, because once it becomes a standard, things can't be changed, only extended.
Best regards,
Martin Plechsmid.
_____
Details:
1) In the standard, there are several things that need a cleaner explanation.
1a) Does the "readOnly" constraint on instance data mean that the corresponding form controls are to be readonly, or that the instance-data value cannot be changed at all (nor by means of xforms:setValue)? 1b) Explain what happens, if the "ref" attribute on a form control refers to no instance-data node. E.g.
......
refer to http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0068.html
--end
1. Agree
2. Agree
3. No. We have the readonly functionality in the model. Caption on output may help. This is purely presentational issue and can be achieved with CSS.
4. No. This is for calculations in the UI. You do the calculation in the model on temporaries and bind to those.
5. Agree.
6. We agree that this is a problem. We will address the problem, but not necessarily using this solution.
7. The effect is achievable in the following ways: toggle and relevant [[give examples]].
8. We agree that it is an issue, but we cannot fix it in this way for technical reasons [[explain]]; can you live with this decision?
The discussion and resolution is archived at:
issue 48.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic37
issue
48.2-http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic38
issue
48.3-http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic39
issue 48.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic40
issue 48.5-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic41
issue 48.6-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic42
issue 48.7-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic43
issue
48.8-http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic44
Subject:
Congratulations on your XForms 1.0 Last Call Working Draft [1]. It is
beautifully produced and something to be proud of.
I have only one substantive request. In 8.10:
"..A limitation of the Schema list datatypes is that whitespace
characters in the storage values (the value="..." attribute of the
item element) are always interpreted as separators between
individual data values. Therefore, authors should avoid using
whitespace characters within storage values with list
simpleContent."
is a major limitation that needs to be fixed. I am sorry I don't
know enough about schemas to be able to suggest how.
What follows are minor editorial comments. They use the "substitute
this for that" convention: s/that/this/
Globally, a small set of proper nouns unique to XForms seem to be
defined. It is important to always capitalize them, or not. (For the
most part they all match.) These include: XForms Processor, XForms User
Interface, XForms Model, and XForms Processing Model. I'm not sure
about Document in 11.
Also globally, s/web/Web/
Globally, s/Schema/schema/ (except XML Schema, the spec)
There are a few "in-your-face" URIs that need to be hidden and given
link text. This may mean adding a few references to appendix B.
http://lists.w3.org/Archives/Public/www-forms-editor/
http://www.w3.org/MarkUp/Forms
http://www.unicode.org/Public/UNIDATA/Scripts.txt
http://java.sun.com/j2se/1.4/docs/api/java/lang/Character.UnicodeBlock.html
http://www.unicode.org/Public/UNIDATA/Blocks.txt
Appendix B has this exactly right (see
http://www.w3.org/2001/06/manual/#References).
In the Abstract, s/Forms for the Web/forms for the Web/
Twice in Status, s/W3C members/W3C Members/
In 1.2, "RFC 2119" needs an [RFC2119] link and RFC 2119 can be a
reference.
In 2.3, s/examples.com/example.com/
s/See (See/(See/
In 4.3.2 1a, s/are be navigated/are to be navigated/ (or are navigated)
In 6.2.1, reword this sentence without gender:
This enables the XForms author [sic] extend external Schemas that she
does not have the ability to change.
becomes:
Thus the XForms author can extend external schemas without having the
ability to change them.
In 7.4.3.1, s/XForms Property/XForms property/ (I think.)
Globally in 8, s/stylesheet/style sheet/ (Generally XSL is one word,
and CSS is two.)
In 8.2 and the image in 10.15, "it will not be visible as you type" is
somewhat misleading. The illustration shows the number of characters in
the password, a bit of information that would help someone crack it.
You might just say "Please enter your password." (The prose is correct
to say, "casual level of security.")
Globally in 8.9 and 8.10 and 8.11.3, s/flavour/flavor/
(Switching back and forth is confusing. W3C uses US spelling.)
In 8.10, s/whitespace/white space/
In 10.1, the two kinds of events could be in an ordered list (ol).
In 10.12, s/empy/empty/
In 10.16, s/XML-Events/XML Events/ and link to XML Events in B.1.
In B.2 FIMS, s/available at/Available at/
In E, all example URIs need to be either example.com, example.org, or
example.net that IANA has reserved for examples (RFC 2606). This
includes xsmiles.org, hut.fi, and examples.com. I will spare the
details and cannot emphasize this enough.
In F, s/Schema/schema/
Three times in G, s/Phillips/Philips/
In G, s/Softquad/SoftQuad/
Twice in G, s/Staff Contact/Team contact/
[1] http://www.w3.org/TR/2002/WD-xforms-20020118/
Best wishes for your project,
--
Susan Lesch http://www.w3.org/People/Lesch/
mailto:lesch@w3.org tel:+1.858.483.4819
World Wide Web Consortium (W3C) http://www.w3.org/
Editorial issues fixed (whew! Thanks Susan!)
* Note: the one substantive issue needs a separate response
* for the comment on images, yes, we are revisiting all images in that
chapter.
* We're also working on making all the examples read 'example.com'
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic13
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic45
Subject:
I have the following concerns about the XForms Last Call Working Draft [1]: o The specification fails to conform to the W3C's Universal Access principle [2]. This principle implies W3C technology should be implementable on any hardware. [1], however, requires an implementation support numerous technologies including: XML Schema Part 1, XML Schema Part 2, DOM 2 Events, XML Events, XPath, XLink, P3P. This is an unacceptable burden for low-end devices. The specification should include layers for the major functionality (e.g. Event, Constraints, User Interface, Actions, etc.). The specification should define modules per XHTML Modularization [3]. Without well defined layers/modules, adoption will be reduced. There will also be partial implementations and thus interoperability problems. o The Status of the Document ([1]) suggests the WG will skip the Candidate Recommendation (CR) phase if the given criteria are met. The W3C should issue an explicit CFP (particularly requesting interoperability feedback) and the CR phase should not be skipped. o [1] states comments should be sent to www-forms@w3.org. Since this is a typo and really should have been www-forms-editor@w3.org, the W3C must assure the numerous comments about [1] that were sent to www-forms are addressed (as if the email was sent to www-forms-editor). The WG's Charter [4] includes Profiles and Test Suites in its list of deliverables. This deliverable does not appear to have materialized - there is no reference to it in [1] or in the WG's Home Page [5]. This deliverable should be considered a "relevant requirement of the charter" per the W3C's Process Document [6]. [1] should not be advanced without this deliverable. Until the above issues are addressed, this document should remain in a Working Draft state. Art Barstow --- [1] http://www.w3.org/TR/2002/WD-xforms-20020118/ [2] http://www.w3.org/Consortium/Points/#universal [3] http://www.w3.org/TR/xhtml-modularization/ [4] http://www.w3.org/MarkUp/Forms/2000/Charter.html [5] http://www.w3.org/MarkUp/Forms/Group/ [6] http://www.w3.org/Consortium/Process-20010719/tr.html#last-call
50.1 Agree. Done. See Basic task force.
50.2 Agree. We will go to CR
50.3 Agree. We have checked for misdirected mails.
50.4 Agree. We will build a test suite.
50.5 We will exit CR on the basis of implementation reports that reference the test suite.
The discussion and resolution is archived at:
issue 50.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic48
issue 50.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic49
issue 50.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic50
issue 50.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic51
Additional thread: http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0080.html
Subject:
Congratulations for this XForms 1.0 Last Call Working Draft. I have the following editorial suggestions, which would ease reading of the spec: I would like to see - an element index - an attribute index - link from element instances to element definition - link from attribute instances to attribute definition Thierry.
Thierry -- an attribute/element index w/ links is dependent on our
stylesheet. We're working on it, but don't have completion date.
Would you be willing to allow CR entry without the index?
Subject:
Hey, This is not very important, but it still seems to me as an ugly bug in the spec: I was doing some UI library stuff based on the xforms controls and noticed that there was a "checkbox" look for selectOne. This does not fit well in any desktop GUI library. A checkbox has traditionally been a control were multiple selections can be made, that is how most people think when they see a checkbox. Also, you already have the "checkbox" selectUI type in the selectMany. Also, I would recommend that you remove the checkbox style from selectOne. You propably should remove radio style from selectMany as well. Otherwise I like the controls, they are nice and abstract, and could propably be used for as interfaces for an cross-device GUI library. juha
(same answer for selectOne/radio and selectMany/checkbox as Msg40)
Subject:
Subject: <output> enchancement blank2 StationeryI would like to suggest to enhancments to the <output> element currently defined as: <output (single node binding attributes) > <!-- empty content --> </output> 1. Allow for a Caption child element. All other Form Controls allow for one and the asymmetry causes a lot of exception coding. 2. In addition to the "ref" attribute provided through the Single Node Binding Attributes, a Value child element would constant value to be output. Thanks, Tim
53.1 Done
53.2 This is the job of the host language.
The discussion and resolution is archived at:
issue 53.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic46
issue 53.2
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic47
Additional threads: http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0084.html
Subject:
It occurs to me that the <schema> and <instance> elements in the XForms
schema should have minOccurs=0 on their definitions, since they are allowed
to have empty content (if an href= attribute is specified, as in the
examples). The default for minOccurs is 1 unless specified, so this would
require at least some content to be present, since processContents is strict
(also the default).
For <schema> I would change:
<xsd:element name="schema">
...
<xsd:any namespace="##other"/>
...
</xsd:element>
to
<xsd:element name="schema">
...
<xsd:any namespace="##other" minOccurs="0"/>
...
</xsd:element>
For <instance> the wildcard would become:
<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
Regards,
-- Steen
/**
* Steen Lehmann -
Editorial issues fixed.
Additional threads:
http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0085.html
http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0086.html
Subject:
Hello XForms WG, The CSS WG has some comments on the "XForms 1.0" WD, but we won't be able to reach consensus on them this week. Below is a list of the things we have been talking about so far, but we may not retain all of them and we haven't decided the wording of them either. If possible, we would like to use the face-to-face next week to finalize the comments and take the opportunity to talk to some of you about them as well, if some XForms people are present on Tuesday. (It would also be a good opportunity to build some shared vision of how the UI of an XForm should be constructed out of XForms mark-up and style sheets.) We will make sure you get the final comments before Thursday, Feb 28. Is that OK? ------------------------------------------------------------------------- (from http://lists.w3.org/Archives/Member/w3c-css-wg/2002JanMar/0231.html) 1) CR exit criteria too weak. Cf. the "Selectors" exit criteria: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/ (from http://lists.w3.org/Archives/Member/w3c-css-wg/2002JanMar/0135.html) 2) The selectMany and selectOne controls should be merged. 3) ... and should have control over minimum and maximum number of selected items. 4) "checkbox" and "radio" style hints should be merged, since they are not a style, but dictated by whether min-select = max-select = 1. 5) ... or radio should not be a valid choice on selectMany and checkbox not a choice for selectOne (from http://lists.w3.org/Archives/Member/w3c-css-wg/2002JanMar/0250.html) 6) HTTP GET should not be deprecated, as its semantics cannot be reproduced by POST. 7) Grammar error: "they" referring to a singular referent. 8) Automatic selection of UI widget based on datatype of INPUT element is not realistic, since datatypes can be user-defined. 9) ID attribute is missing from "common attributes" On behalf of the CSS WG, Bert
1. Agree. Exit criteria will be based on test suite.
2. Disagree. [[Need pointer to discussion at Cannes FtF on merging select1 and select many]]
3. This functionality is in the model and not in the control: if you bind to complex types then the minOccurs and maxOccurs apply.
4/5. We will do this. Now called: appearance="full|compact|minimal|Qname-but-not-ncname". Applies to all forms controls.
6. Agree (PUT method)
7. No, you are wrong. See http://www.crossmyt.com/hc/linghebr/sgtheirl.html
8. No, because all user-defined datatypes are based on built-in datatypes.
9. This is a function of the host language. We just require an attribute of type ID, whose name may differ per host language.
The discussion and resolution is archived at: (Copenhagen)
Subject:
The XForms Last Call spec disallows in 3.2 other namespaced elements within XForms
elements. This makes extending XForms hard and clashes with the X in XML (Extensible).
For instance, it might be desired for an implementation to create a action handler in its
own namespace:
<xforms:button>
<xforms:action ev:event="click">
<x:sign model="modelid"/>
<xforms:submitInstance model="modelid"/>
</xforms:action>
</xforms:button>
PROPOSED SOLUTION:
Allow other namespaced elements everywhere within the XForms elements and ignore them (the same as with other namespaced attributes
currently).
- Mikko Honkala
Added <extension> and mustUnderstand. (Accepted by submitter: Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic55
Subject:
Below are the comments from the XML Schema Working Group on the XForms
January 18th Working Draft
Regards
Martin Gudgin
For the XML Schema Working Group
Comments;
1. Section 3.2 refers to a type called xsd:idref, should be xsd:IDREF
2. Section 6.3.2 - The example is incorrect. It will always assign a type
of xsd:string to instance data, rather than the anonymous inline simpleType.
Should be rewritten using a named type;
<xsd:simpleType name='CCType' >
<xsd:restriction base="xsd:string">
<xsd:enumeration value="MusterCard"/>
<xsd:enumeration value="Donor'sClub"/>
<xsd:enumeration value="WildExpress"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType>
<xsd:union memberTypes="tns:CCType" xsd:string"/> </xsd:simpleType>
3. Section 6.3.3. - Union. This section may make more sense before 6.3.2
given that 6.3.2 uses union
4. Schema for XForms -
<xsd:attributeGroup name="commonUIAttributes">
<xsd:attribute ref="xml:lang" type="xsd:language" use="optional"/>
<xsd:attribute name="class" type="xsd:string" use="optional"/>
<xsd:attribute name="accessKey" type="xsd:string" use="optional"/>
<xsd:attribute name="navIndex" type="xsd:nonNegativeInteger"
use="optional"/>
</xsd:attributeGroup>
should be
<xsd:attributeGroup name="commonUIAttributes">
<xsd:attribute ref="xml:lang" use="optional"/>
<xsd:attribute name="class" type="xsd:string" use="optional"/>
<xsd:attribute name="accessKey" type="xsd:string" use="optional"/>
<xsd:attribute name="navIndex" type="xsd:nonNegativeInteger"
use="optional"/>
</xsd:attributeGroup>
5. Schema for XForms -
<xsd:element name="group">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="xforms:caption" minOccurs="0"/>
<xsd:any namespace="##any"/>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:horzAttrs"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
<xsd:attributeGroup ref="xforms:commonUIAttributes"/>
</xsd:complexType>
</xsd:element>
has an ambiguous content model. Some possible solutions;
a) Make caption mandatory ( minOccurs='1' )
b) Remove the reference to caption altogether ( content model would just
contain the wildcard ). c) Put in a choice listing all the xforms elements
that are valid, followed by a ##other wildcard. e.g.
<xsd:element name="group">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="xforms:caption" minOccurs="0"/>
<xsd:choice>
<xsd:element ref='xforms:input' />
<xsd:element ref='xforms:secret' />
<xsd:element ref='xforms:textarea' />
<!-- other xforms elements
</xsd:choice>
<xsd:any namespace="##other"/>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:horzAttrs"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
<xsd:attributeGroup ref="xforms:commonUIAttributes"/>
</xsd:complexType>
</xsd:element>
d) put all the elements in the choice above into a substitution group. Make
type of the head of the substitution group be the ur-type.
<xsd:element name='XFormsHead' abstract='true' />
<xsd:element name='input' substitutionGroup='xforms:XFormsHead' ...>
...
</xsd:element>
<!-- other xforms elements also use
substitutionGroup='xforms'XFormsHead' as appropriate -->
<xsd:element name="group">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="xforms:caption" minOccurs="0"/>
<xsd:element ref='xforms:XFormsHead' />
<xsd:any namespace="##other"/>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:horzAttrs"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attributeGroup ref="xforms:bindFirstAttributes"/>
<xsd:attributeGroup ref="xforms:commonUIAttributes"/>
</xsd:complexType>
</xsd:element>
6. Schema for XForms -
<xsd:element name="model">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="xforms:instance" minOccurs="0"/>
<xsd:element ref="xforms:schema" minOccurs="0"/>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element ref="xforms:submitInfo"/>
<xsd:element ref="xforms:privacy"/>
<xsd:element ref="xforms:bind"/>
<xsd:element ref="xforms:action"/>
<xsd:element ref="xforms:extension"/>
</xsd:choice>
</xsd:sequence>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:horzAttrs"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="extensionFunctions" type="xforms:QNameList"
use="optional"/>
</xsd:complexType>
</xsd:element>
has a redundant sequence. Could be rewritten as;
<xsd:element name="model">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="xforms:instance" minOccurs="0"/>
<xsd:element ref="xforms:schema" minOccurs="0"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="xforms:submitInfo"/>
<xsd:element ref="xforms:privacy"/>
<xsd:element ref="xforms:bind"/>
<xsd:element ref="xforms:action"/>
<xsd:element ref="xforms:extension"/>
</xsd:choice>
</xsd:sequence>
<xsd:attributeGroup ref="xforms:horzAttrs"/>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="extensionFunctions" type="xforms:QNameList"
use="optional"/>
</xsd:complexType>
</xsd:element>
7. Schema for XForms -
All wildcards have processContents='strict' ( as this is the default
value ). Is this the intention? Or should they be marked
processContents='lax'?
8. Schema for XForms -
Many wildcards ( in schema, caption, hint, help, alert, extension, value
element decls ) are single occurence. While others ( in instance, group,
case, repeat element decls ) are unbounded. Is this correct? Or should they
all be unbounded?
9. Schema for XForms -
In all but two cases (extension and value), the ID attribute and the
horzAttrs AttributeGroup are used together. Why not make an AttributeGroup
containing them?
1) yes
2) yes
3) editor's choice
4) yes
5) Accept solution c)
6) yes (editorial)
7) We have no idea. Please tell us.
8) Yes it was wrong. We will fix.
9) Agree.
The discussion and resolution is archived at: (Copenhagen)
Subject:
If submitInstance is specified without the submitInfo attribute, which submitInfo element in the model is used? The first one in document order? Section 10.8 of the latest draft says submitInfo is optional.
The IDREF attribute should have been required. This is fixed.
The discussion and resolution is archived at:
Subject:
Section 10.5 says that setFocus works by issuing an xforms:focus event to the target, but section 4.3.3 says that xforms:focus is a notification event only and has no default processing. -Ray
Yes, setfocus is fixed in the events roundup.
Subject:
Right now, setFocus and toggle both work by using an ID. I propose adding a "ref" attribute to allow them to compute this ID via XPath expression. The use case is to toggle a switch/case dynamically or transfer focus dynamically. For example, you have a form taking a purchase order and the person can pay by Credit Card, Check, or PayPal. Based on a <selectOne>, the person choses their payment method, you would then like to <toggle> 3 different UIs based on the selection value. -Ray
Not needed. Use case can be done in several ways, such as using relevant property in the model. (Copenhagen FtF resolution)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic58
Subject:
Should XForms import some required functions into its core XPath library for date manipulation? (date arithmetic, extraction of date values such as month, day, year, timezone, etc) For example, one might wish to use the now() function, extract the timezone, and use it to determine other parts of the form.
Agreed. We have done this.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic59
Additional threads: http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0114.html
Subject:
Gentlepeople,
this is the official review by the P3P Specification Working Group of the XForms 1.0 Working
Draft (http://www.w3.org/TR/2002/WD-xforms-20020118/ ), currently in Last Call.
The P3P Specification Working Group, after analyzing the XForms specification, has identified
two major issues ("P3P-HOOK" and "P3P-DATATYPES"), explained below, and feels that both
issues should be appropriately tackled before XForms can advance.
Other minor comments follow.
Best regards,
-Massimo
on behalf of the P3P Specification Working Group
--------------------------------
ISSUE "P3P-HOOK" :
XForms (optionally) associates a form to a P3P policy reference file, via the "privacy" element.
P3P is mentioned in two parts of the document:
- in Section 3.7 (Privacy):
> Element privacy is used to associate a P3P [P3P 1.0] policy reference with a particular form.
- in 4.2.2. (default processing for the xforms:modelInitialize event):
> 2. If applicable, P3P has been initialized. [P3P 1.0]"
This is a rather short description, and what this actually means is not extremely clear.
Trying to interprete, the intended behaviour should be that the privacy element allows to
reference a policy reference file, that in all likelihood pertains to the form: so, this
covers that portion of the URI-space where XForms' submitInfo lies (including "action",
but also "method"). Note en passant that interaction between XForm's "method" and P3P's "METHOD"
should be further clarified, as they are different. And maybe, a requirement that the policy reference
file SHOULD pertain to the pointed action-method (however defined) is in order here too.
Moreover, confusion with the P3P's policy concerning the URI where the xforms lies could arise
(incidentally, note that P3P now supports XHTML as well, so this could be profitably mentioned).
So, all this should be stated with a more detailed and precise description, and already some
possible troubles come up.
But, just trying to be more formal and precise, another problem creeps in here, and it's part
of the more general problem of other applications trying to define hooks to P3P.
Think again of the inteded behaviour stated above: now, what's the behaviour
where that same part of URI space is covered eg by a P3P header, referring
to a different policy reference file? What are the precedence rules for a P3P agent?
The point is that XForms' "privacy" element is introducing another way for an application
to locate a P3P policy reference file, but it is unclear how a conforming P3P agent should behave
in this case (since this method is not in the P3P spec).
Different solutions are possible, each with its pro's and con's: the P3P Specification working group
feels therefore that this important issue should be a matter of further discussion and coordination
between the working groups, until a satisfactory solution is found.
--------------------------------
ISSUE "P3P-DATATYPES" :
XForms now allows to associate some meta-information to each piece of data it collects. This includes
structural information (using XML Schema). But, alas, it doesn't include semantical information,
that can be made readily available using P3P's dataschemas.
XForms could seamlessly provide this kind of information by adding an (optional) attribute (e.g.,
to <caption>) where one can attach to the datum a P3P semantic datatype (that is referenceable
by using a URI). This is the route already followed by, for example, CC/PP.
This would have many benefits, as intelligent UI's and agents could then have much more
meaningful information on what fields are collected, and act appropriately. For example, part
of an xform could be evaluated wrt a privacy policy with a finer level of granularity.
Also, *automatic fill-in* of form fields could be possible, eg interacting with e-wallets.
Even, this could simplify writing and maintaining P3P policies when dealing with many complex and
time-changing xforms: one could just write a generic "catch-all-data" P3P policy for xforms
and be more precise on what data is collected not in the P3P policy, but in the specific xforms.
Therefore, the P3P Specification WG strongly encourages introduction in XForms of P3P semantic datatype
information.
--------------------------------
Other minor comments:
(note these comments refer to the current version of the XForms spec; dealing with the "P3P-HOOK" issue
could in fact make some of these minor remarks just not applicable).
+ The xlink:href attribute of xform's <privacy> is optional: it probably makes more sense to make it
mandatory (since <privacy> itself is optional).
+ Multiple "privacy" elements are possible, but this can only be derived from the XForms schema, and
it not mentioned anywhere else in the specification (in any case, behaviour in presence of multiple
policy elements should be explained).
+ The P3P ref in the bibliography, eventually, should be updated.
+ The P3P ref should be put in the normative references, and not left in the informative ones.
1. Agreed on a teleconference with P3P representatives [ref] to remove <privacy> element.
2. Agreed to add P3P datatypes.
3. (Additional) agreed to add text about use of P3P with XForms.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic29
issue 62.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic30
62.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic31
http://lists.w3.org/Archives/Member/w3c-forms/2002AprJun/0351.html
Subject:
Hello, In section 2.3. In the instanceData xml example, shouldn't "Credit" be "credit" ? This is a confusing typo for a beginner. If this is not, then you should explain. Here is the orginal: <instanceData> <as>Credit</as> <cc>1235467789012345</cc> <exp>2001-08</exp> </instanceData> Best regards, Nicolas Romanetti
Editorial issue fixed.
Subject:
The 'poll' example in section 2.6 shows the submitInfo attribute value holding the ID of a 'model' element whereas the intent would seem to be that this should hold the ID of a 'submitInfo' element inside some 'model' element. The example earlier in section 2 does show it this other way. In some cases you have explicitly added a sentence declaring it to be an error where, for example, the IDREF value in a 'model' attribute is the ID of an element other than a 'model' element. Do you want to pull that out as a separate sentence as regards this submitInfo linkage? Isn't there a way to get this kind of a constraint into the schema? Al
Editorial issue fixed.
Subject:
The Last Call XForms spec says, that the form controls do not update invalid values to the instance. I would like to question this decision and claim that also invalid values should be allowed to be updated in the instance. My arguments are the following: CONSISTENCY * invalidity based on constraint 'isValid' is always based on the instance anyway, so an implementation actually cannot know whether a piece of data is 'isValid' without putting the value in the instance and running the calculations. * <setValue>, calculate constraint, and scripts will be able to put invalid values in the instance * Keeping some information in the UI control rather than in the instance breaks our data/UI separation. That can confuse 2 operations hard: a)multiple controls binding to the same node b) saving the current state of the form. ERROR MESSAGES * if the invalid value was put in the instance, it would be possible to create error messages using that value. Currently the invalid value is not accessible throught the instance. FEASIBILITY * some implementations are using external schema validator, that allows only revalidating the whole/parts of the instance. PROPOSED SPEC CHANGE: -------------------- - remove valueChanging event - if support for single character updates in a single <input> control are required, add an attribute 'update' to <input>, and update the instance for every character.
xResolved and accepted.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic61
Subject:
Dear Editors: Attached pleaase find the general comment on XForms 1.0 WD dated January 18, 2002. Best Regards, Toshihiko Yamakami, R&D, ACCESS yam@access.co.jp ================ Comments for Last Call WD of XForms(http://www.w3.org/TR/2002/WD-xforms-20020118) From ACCESS 020221 This is a general comment on XForms WD 18 January 2002 (Last Call) from ACCESS. We witness the emergence of browser-enabled mobile handsets all over the world[1]. After three years from launch, there are more than 50 million browser-enabled mobile handsets Internet users in Japan. No one denies that this trend of Internet on the palm will be spread all over the world in a very near future. We also witness the significant amount of standardization and industrial consortium work on making specifications for mobile handsets and Internationalization. We think it is a time to reconsider the standards specification format in order to make the various kinds of works for compact profiles and international compact profile. For this purpose, every drafting team for recommendations should take into account that a draft can be composed as three parts: language independent core part, language independent extension part, and language dependent part. It could be accomplished by some framework, modular structure, guidelines, or informal notes. Reading the XForms 1.0 draft, it seems like that "D input Modes" attribute heavily depends on the input target language (here, language means English, Japanese, Chinese, Korean, and such category of human communication symbol systems). Also the requirements of XForms like "strong typing" and "XML submission" are useful in browser-embedded mobile phone environment. It would be desirable which part of the draft is mandatory when these minimum requirements are met. We agree that the many of the XForms features depends on the XML features like namespaces and such high level features are not available on the most mobile handsets. This means it is very difficult to predict that the how people can make a compact profile for XForms. In any case, compact profiles and internationalization will take place sooner or later to cope with the real world problems. We hope that the systematic approach to the standards could remove many of the common pains on the standardization related activities on this planet. Reference: [1]$B!H(BBeyond the Post-PC Internet$B!I(B Vinton Cerf, CACM, Vol.44, No. 9, Sep 2001, pp. 34-37$B!! (Bin the Special issue $B!H(BThe Invisible Internet$B!I(B.
We agree that conformance levels must be better described. You are correct that "D input Modes" heavily depend on the input language. The spec says this already. We haven't split the specification in the way you suggested, but we hope you can live with this situation.
The discussion and resolution is archived at:
issue 66-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic63
issue 66.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic64
issue 66.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic65
issue 66.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic66
Subject:
I have some concerns about the exit criteria for XForms 1.0 listed in the section of the document titled 'Status of this Document'. Of specific concern are the two statements: 1. Sufficient reports of implementation experience have been gathered to demonstrate that XForms processors based on the specification are implementable and have compatible behavior. 2. An implementation report shows that there is at least one implementation of each feature. My basic concerns with these statements are... Statement 1 needs more definition than 'sufficient'. Statement 2 falls way short of what will be needed to ensure that XForms is viable and usable. Interoperability is required to establish that a feature is not only implemented correctly, but specified correctly. Also, to have an implementation of each feature does not establish that the feature will work in real world situations or will make sense in the context of an application. Changes Needed: I believe the following changes to the exit criteria are needed to address these issues. 1. There must be a test suite that specifies a test for each feature of XForms plus many interaction features. See http://www.w3.org/Graphics/SVG/Test/BE-ImpStatus-20010127 for an example of exit criteria that specifies this. 2. There must be more than one implementation of each feature and there must be interoperability between each. For an example of this, take a look at the CSS3 Selectors test suite at http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20020115/. "There must be at least two interoperable implementations for every feature". Note the definition of 'implementation' in this test suite which includes 'available', 'shipping' and 'not experimental'. I think it is a good one. 3. There must be real application of the spec. This goes beyond building a designer tool that generates XForm markup and a viewing tool that displays it and allows a user to fill out a form and submits it. There must be people who implement real projects using tools that generate XForm markup and tools that allow users to fill out forms and process the results on a server. There needs to be people building credit card applications, order forms, surveys, and all kinds of applications. Each of these has the potential to uncover new problems with the specification that were not apparent in the design or even the implementation of the tools. The Canonical XML recommendation (http://www.w3.org/TR/xml-exc-c14n) specifies a stronger implementation criteria as in 2 above and satisfaction in an application context as this item 3 insists. From Canonical XML: "at least two interoperable implementations over every feature, one implementation of all features, and one report of satisfaction in an application context" It is a goal of XForms 1.0 to make forms declarative such that many forms will not require scripting. This will not be remotely achievable if each person publishing a form has to plug in script to work around the holes that were not exposed by this kind of real-world testing. We could end up in a situation much like we have today with HTML forms where every form requires script. This will significantly slow the adoption of XForms into the areas it needs to go or halt it's adoption completely. That would be a colossal waste of everyone's time invested in this specification. A Call to Action: A natural objection to these comments is that it will take more time. It will. And we do have to be concerned about taking too much time. But somewhere we have to find a balance. And for some of us, this is simply a matter of will. Are we willing not just to finish an XForms specification, but to do what is necessary to see it successfully adopted? Considering the great benefits to the entire community of achieving recommendation status sooner rather than later, Cardiff is prepared to contribute to the development of a test suite and to move aggressively to implement the design side of an implementation. Who else will contribute to the development of a test suite? Who will commit to developing viewing tools? Who will commit to using these design and viewing tools to build real world applications? I am convinced that the best thing we can do for XForms right now is to all move aggressively to invest in all of these areas. All of these things are needed for XForms to ultimately be successful. J Joel Faul, Director, Internet Product Development
Indeed we plan to go to CR. We will exit CR on the basis of implementation reports that reference a test suite.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic67
Rejected: http://lists.w3.org/Archives/Public/www-forms-editor/2002Jul0057.html
Subject:
Dear XForms WG, I found some more time to look through XForms. Below are the most important comments. I have a lot of small editorial comments, too, but I suggest that it's more efficient if I sit together with some of you next week in Cannes. I have copied the I18N IG because many of my comments are I18N-related; the I18N WG may want (or not) to endorse some of these comments, although that will not be possible before the end of the official last call period. [I18N IG: Please note that the www-forms-editor@w3.org is publicly archived.] - IRI/anyURI: There should be a note that data of type anyURI, and xlink:href, are internationalized. Otherwise, it's easy for implementers to miss this. A wording like in XML Signature (sorry no pointer, currently offline) is a good start. It could go into 3.2 and/or 3.8. The spec should make clear that the conversion (->UTF-8->%HH) only happens when anyURIs get resolved, not in XForms or as part of an instance. - Bidi: I remember Jonathan Rosenne once making a comment about a problem with bidirectionality and HTML forms. I think it was that the base direction of an input field, as used by the user, could not be transmitted to the server. This is also a problem for XForms. Even more, there is no way to set the base directionality for an input field. This looks like a step back from HTML. (Please note that the base directionality of a text is related to the semantics of that text, and not just a presentation issue.) [A generalization of this is complex types as single form controls, e.g. for HTML fragment input,... My personal opinion is that the WG should at least have an idea of how they plan to add that in a later version.] - In 2.2, an example with a Date is given. The HTML example is not very good, because usually, there are separate fields for month and year of the expiration date. An XForms example of the presentation to the user is not given. If the user is supposed to type in 2002-03, this just won't work anywhere in the world. It is also not very clear how the gYearMonth type would get translated into a reasonable UI component (in particular because it may be localized, where e.g. in Japan, the year would come first, with the consequences that many people would interpret the first two digits as the year rather than the month. There are several more problems with dates. In particular, I think that in section 8.1, it is very important to say clearly that a simple text field is not a good idea for date input. - 7.4.1.1: Only allowing 'true' and 'false' for boolean values is more language-dependent than necessary. '0' and '1' should also be allowed, also to fit with XML Schema. Regards, Martin.
1) Agree. We have added a note about the i18n benefits of xsd:anyURI.
2) Your comment had no specific suggestion... This is a host-language
issue.
3) Agreed. We now include an example of "calendar" date entry
4) Agree. boolean-from-string() has been changed as suggested.
The discussion and resolution is archived at:
issue 68-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic142
issue 68.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic143
issue 68.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic144
issue 68.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic145
issue 68.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic146
Subject:
Plechsmíd Martin <Martin.Plechsmid@merlin.cz> wrote
http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0068.html
6) I suggest to allow more than one xforms:instance element in one
xforms:model.
---
Martin had lots of thoughtful feedback, but I would like to reinforce this
one particular point.
A general design principle in XForms is that the initial instance/submitted
instance can be arbitrary XML. Cardiff's implementation experience in
attaching forms to XML systems bears this out: any additional layer needed
between the existing XML and the form creates massive maintenance and
support issues. (this is one problem with HTML forms that we look to XForms
to solve)
So, we would like to pipe XML directly into the form, with no intermediate
steps. Currently, this is difficult in many cases.
It is common to have a situation where:
1) The XML format delivered by the server is difficult or impossible to
alter, and
2) A form based on this XML needs non-submitted temporary values. Since the
XML structure is fixed, there's no place for these temporary nodes.
Martin's suggestion (along with the ability to submit a subtree) is one
possible solution. Other possibilities include, in order of preference:
a) Allow cross-instance access. A method such as instance() that returns the
root node of another instance would allow all the temporary data to be
stored in a separate instance and accessed when needed.
b) Instead of the "either-or" processing of inline vs. linked initial
instance data, make it "and" processing. In other words, if the <instance>
element contains both inline content and an xlink:href attribute, take both
and merge. Thus, the temporary area could be inline XML while still getting
the actual data from the server. Using subtree submit, the submitted XML
could still be structurally identical with the incoming XML.
c) Explicit temporary variables. get("name", "value") and set("name",
value")
Thank you for considering this,
.micah
allowing multiple <instance> elements within a single XForms Model, and having a instance() XPath function that returns the root element of a given instance.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic68
Subject:
The description of 'accesskey' functionality reads very much like what is in HTML 4.01. There are some outstanding problems with this description as a specification. Please consider rewriting the section on 'accesskey' more along the lines of the specification language as recommended by the WAI to the SMIL developers for SMIL 2.0. For this language please see http://lists.w3.org/Archives/Member/wai-liaison/2000Nov/0000 For a further discussion of the current problems, please see the accesskey discussion in http://www.w3.org/WAI/PF/Group/xhtml2.html You may wish to consider this injection of accesskey functionality part of the forms binding to an interface within a host language. While form controls are typically among the high-priority navigate-to items in a host-language document, the provision of orderly navigation requires knowing what all the aspects are embraced by the host language and may perhaps not be well addressed on a module by module basis. Al Process status: This is a concern of some long standing about HTML (all flavors with hopes to get something better in XHTML 2.0). The language proposed to SMIL 2.0 resulted from considered discussion and some back and forth with that group and should be taken as semi-mature. The rest of the ideas are offered on a FWIW basis if they perhaps may help.
Agree. We will add this text to the definition of accesskey.
SPEC CHANGE
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic70
Subject:
[This is an individual comment, not consensed on by any group in particular.]
In the Last Call Draft the exit and decision criteria for this review are stated as follows:
Following completion of Last Call, the XForms Working Group has agreed
to advance the specification according to the following exit criteria:
1. Sufficient reports of implementation experience have been gathered
to demonstrate that XForms processors based on the specification
are implementable and have compatible behavior.
2. An implementation report shows that there is at least one
implementation of each feature.
3. Formal responses to all comments received by the Working Group.
If these criteria are met, the specification will advance to Proposed
Recommendation, otherwise the specification will enter a Candidate
Recommendation phase to ensure that the above criteria are met.
This discussion does not address what could be a key risk area: the dependency of this technology
on other technologies which are not yet fully stable at this time.
Such dependencies could be considered to include, say, XML Events, X Pointer, and one might
mention X Link as well.
X Forms is an advanced kind of product, a more pure 'resource module' than the W3C has produced
before. The way the host language all comes together is complex. This language-building area is
one where, once again, there are non-trivial divisions in the community.
Under the circumstances the above stability criteria may be too weak, and the intent to advance
to Proposed Recommendation too agressive, to be the best choice.
Please consider all these factors before the group comes to a decision on next steps.
Al
We have launched an XForms Basic task force to ensure that dependencies on other specifications do not hinder adoption of XForms. The messages on this topic are in the public archive at www-forms@w3.org. We have also factored out the XLink dependency, which you specifically highlighted. We are also actively working with the HTML Working Group to define a combined XHTML+XForms profile, which has the desirable side-effect of identifying all the necessary integration points.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic71
Additional threads: http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0113.html
Subject:
The Abstract for XForms 1.0 says: "XForms is not a free-standing document type, but is intended to be integrated into other markup languages, such as XHTML." However, some parts of the specification still read as if XForms _is_ a standalone document type. The Working Group should consider simplifying the specification: * Does the conformance section really make sense? Would it be better to have a conformance section along the lines of XPath (another 'building block' specification): <quote> XPath is intended primarily as a component that can be used by other specifications. Therefore, XPath relies on specifications that use XPath (such as [XPointer] and [XSLT]) to specify criteria for conformance of implementations of XPath and does not define any conformance criteria for independent implementations of XPath. </quote> * Along the same lines, are "XForms Basic" and "XForms Full" really "conformance profiles", or actually "modules"? * Does the linkage between XForms and a particular transport (such as HTTP GET, PUT, & POST) really make sense? Or should the XForms specification 'exist in a vacuum', with specific bindings occurring at the level of specific document profiles (XHTML+XForms, etc.) * Do the extensibility measures in XForms consistently reflect the status of XForms as a building-block spec? I request that the XForms Working Group begin the effort of defining an XHTML+XForms document profile. Going though this will help identify and clarify all the interface points between XForms and the rest of the world. This effort is in distinct from any XForms-as-part-of-XHTML-2.0 work that is underway, though much re-use is likely possible. Thanks, .micah
Indeed, we will work on a XHTML+XForms example profile.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic83
Subject:
As of today, the DOM WG do not have comments regarding the XForms draft at: http://www.w3.org/TR/2002/WD-xforms-20020118 Philippe, for the DOM WG.
(None required)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic84
Subject:
During the Last Call period for XForms, from 18 Jan to 22 Feb 2002, the following comments appeared on www-forms, the mailing list for general discussion of XForms. Overall, Working Group members did a thorough job of directing people to the correct list for their comments (for example [1]), so many of these comments may be duplicated on www-forms-editor. Nevertheless, in the interest of throughness and fairness, I include links below. Ordinary discussion traffic, especially when a particular question has been answered, is not included here. "About the bind element" from Jérôme Nègr; 18 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0103.html "XForms Basic." from John J. Barton; 18 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0104.html "Repeating nested structures" from Naresh Bhatia; 21 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0111.html "Re: FORMs and GET" from Paul Prescod; 21 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0119.html [note: the specific issue is the ';' vs '&' character is urlencoding "XML Schema for XLink" from Vun Kannon, David; 24 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0153.html "Should we really care about legacy?" from Werner Donné; 25 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0155.html "Dynamic dropdown data sources" from Dave Johnson; 31 Jan http://lists.w3.org/Archives/Public/www-forms/2002Jan/0172.html "Other controls ? Grid ?" from DESEYNE Jacques; 1 Feb http://lists.w3.org/Archives/Public/www-forms/2002Feb/0000.html "How dynamic are <itemset>s ?" from Jérôme Nègr; 8 Feb http://lists.w3.org/Archives/Public/www-forms/2002Feb/0023.html "Using xlink:href in caption/hint/help" from Tomayko, Ryan; 17 Feb http://lists.w3.org/Archives/Public/www-forms/2002Feb/0033.html Sincerely, .micah [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0154.html
To deal with these comments, I suggest we send the following note out to the 10 senders identified:
Dear <name>, Re: <URL> During the Last Call comment period for XForms, you sent a message to the XForms public mailing list that has been identified as a potential Last Call comment. If you intended this message as a formal Last Call comment, but accidentally sent it to www-forms@w3.org instead of www-forms-editor@w3.org, please respond in the affirmative to this message within the next two weeks. Sincerely,
The discussion and resolution is archived at:
Archived: http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0107.html
Subject:
XForms uses XPath for its underlying expression model and XML Schema for its data typing. However, the current version of XPath doesn't understand XML Schema data types (I've heard that XPath 2.0 will...). It is very common on forms to want to manipulate dates and times. Examples appear in validations (e.g. a date is valid if it is within 7 days of the current date) and calculations (e.g. on a time card summing the number of hours worked). XForms needs to address this and make it easy for users to perform such calculations. I see two paths: 1. Add functions to the XPath core library to allow dates and times to be converted to/from some numeric format. 2. Add functions to the XPath core library to perform calculations on date/times/durations. For example: compareDate( d1, d2 ); // returns: -1 if d1 < d2, 0 if d1 == d2, 1 if d1 > d2 addToDate( date, duration ); // adds duration to date and returns the result as a date dateDuration(start, end); // calculates end - start and returns as a duration. similar functions would be needed for date-times and times. Also, it would be very useful to specify exactly what the results are of adding a duration to a date if when the duration specifies a month: i.e. "2000-2-1" + "P1M" == ??? (is it date + 30 days or is it "2000-3-1") Tom Keane Director, Core Technologies CARDIFF, Inc.
We agree with the need to manipulate dates, and have added functionality.
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic60
Subject:
Subject: There is a sequence of initialization events defined for the XForms model, but there is no equivalent event for when the model is destroyed. Very often form designers have the need to do something when a form is loaded or initialized and then undo it when the form goes away (e.g. acquire/release a resource). In the current XForms model there is no way to address this. I understand that there will be a need to clearly define the behavior of the initialization events and the destruct event in the context of common web user actions (e.g. when the user clicks on the 'back' button on the browser). I think a good model to start from would be that which is used in HTML for the onload() and onunload() events for the <BODY> element. In theory it would be possible for users to simulate the behavior of modelDestruct() by calling a function from the containing document's onunload() event, but this adds an ugly dependency and prohibits designers from creating forms as self-contained entities. Thank you, Tom Keane Director, Core Technologies CARDIFF, Inc.
We have added event: xforms-model-destruct
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic101
Subject:
This proposal addresses two cases that come up in form design: 1. The need for 'temporary' variables 2. Pulling instance data from more than one source. The current XForm spec allows the 'instance' node of model to either define inline content or to declare an XLink from which to pull the instance data. This seems limiting. It does not allow the form designer to add any variables to the instance data and it does not allow instance data to be pulled from more than one source. I would propose a method to insert XML data pulled from an XLink reference into a sub-tree of model/instance. <model> <instance> <hiddenvariable1 /> <hiddenvariable2 /> <zipcodeinfo /> <profiledata /> </instance> <externalInstanceData ref="zipcodeinfo" xlink:href="..." /> <externalInstanceData ref="profiledata" xlink:href="..." /> ... </model> When the model is initialized, whatever XML data is retrieved from the xlink:href would be inserted under the node indicated by the ref attribute. Tom Keane Director, Core Technologies CARDIFF, Inc.
We have done something similar: namely allowed more than one instance in a model. (Copenhagen FtF)
The discussion and resolution is archived at:
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic69
Subject:
[This is a personal comment, not a group comment.] In the current language of the XForms specification it is allowed to leave the 'model' attribute of a form control un-stated in the XML text of the control and the control will be associated with the textually-first model appearing in the enclosing host document. This rule saves characters, and it is particularly appealing in the context of a document with a single form (only one model element). On the other hand, this is the sort of thing that can prove brittle in use. One can expect error in the use of something this subtle. It could be safer to allow defaulting only in the case where there is a unique model in the appropriate scope. In addition, the defaulting may perhaps dump just enough burden on assistive technology so that useful assistive functions don't get performed. In the development of the User Agent Accessibility Guidelines, the group came to a consensus in port of the idea that people in some disability-related delivery contexts; such as people using speech and not braille as the output of their screen readers, easily get confused about the scopes of forms. This confusion can include not grasping what is to be submitted by a 'submit' element or reset by a 'reset' element. In legacy HTML the enclosing FORM element makes the hope clear in a way that an assistive technology can readily pick up, say from the DOM. Related assistive functions could be things such as to move to the start of the current FORM, to the end, to clear it, or to tour just the controls within it for a review of the state of affairs -- what in the new edition is the state of the "instance." Now, with the defaulting rules in place the logical definition of the XForms aspect of a document instance does define a unique 'model' element governing each form control. But some of the associations may be explicit and some implicit. The most likely DOM content will be to capture only the things that are explicit. So an assistive technology wishing to add "review current form" capability will have to reconstruct the control-to-model associations wherever they are defaulted. This takes a full tree-walk to find all the model and form control elements. This could be done on the order of once per load by a DOM service routine, but it is enough of a hore so that it could be the straw that broke the camel's back, the burden that kept the assistive technology from implementing this function. Another angle is that defaulting should perhaps be a host language option. The correct functioning of the form only requires that the effective governing model is known. If all such references are explicit, the form works. If the language provides defaulting that is well-posed that is to say deterministic, it also works. The rule of the textually first model in the enclosing document may not be a good one in all contexts. At least in real-time streaming At least in real-time streaming contexts it may be undesirable. So this is an area where it is questionable whether the XForms resouce module should the XForms resouce module should define the defaulting. Just that host languages should either require the 'model' attribute to be always present, or define suitable defaulting. Please consider this before going forward with the current defaulting policy. Al
Resolution: If there is more than one model in a containing document there must be an ID on each one, and anything outside any model that binds to a model must specify either a 'bind' attribute or both a 'model' attribute and a 'ref'/'nodeset'. With only one model, the ID is optional, as is the 'model' attribute.
The discussion and resolution is archived at:
issue 78-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic102
issue 78.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic103
issue 78.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic104
Subject:
There is a sequence of initialization events defined for the XForms model, but there is no equivalent event for when the model is destroyed. Very often form designers have the need to do something when a form is loaded or initialized and then undo it when the form goes away (e.g. acquire/release a resource). In the current XForms model there is no way to address this. I understand that there will be a need to clearly define the behavior of the initialization events and the destruct event in the context of common web user actions (e.g. when the user clicks on the 'back' button on the browser). I think a good model to start from would be that which is used in HTML for the onload() and onunload() events for the <BODY> element. In theory it would be possible for users to simulate the behavior of modelDestruct() by calling a function from the containing document's onunload() event, but this adds an ugly dependency and prohibits designers from creating forms as self-contained entities. Thank you, Tom Keane Director, Core Technologies CARDIFF, Inc.
(None required; see message 76)
The discussion and resolution is archived at:
same issue as Message 76
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic105
Subject:
Attached are some comments on the 18 January 2002 XForms draft. Sorry they are so late. -- Shane P. McCarronInet: shane@aptest.com Managing DirectorPhone: +1 763 786-8160 x120 This document contains my comments on the XForms 1.0 draft from 18 January 2002. This review is NOT a complete testability analysis, but does contain comments that are relevant to the testability of any implementation of this specification. It also contains editorial comments, usability comments, and technical comments. Since there is no formal commenting structure or content mechanism, I have tried to present my comments sensibly. Note that each comment is separated by a line containing only '-----'. This SHOULD make it easy to separate the comments. ----- Number: 1 Section: All Paragraph: All Type: technical Priority: high Problem: This specification uses "camel-case" for attibute names. While I personally prefer that, the HTML Working Group has elected to avoid using this convention because of the difficulty it causes users. Recommended Solution: Change the attribute names to all lower-case. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic106 ----- Number: 2 Section: All Paragraph: All Type: technical Priority: high Problem: Throughout the document there are some normative, "assertive" terms used. Some of these are defined by reference to RFC 2119. Others are not defined, and they need to be. Recommended Solution: Add definitions for "undefined", "unspecified", and "implementation defined". The latter is not used in this specification yet, but it should be in a few cases (see my later comments). [Yes, I will assist with defining these terms.] The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic107 ----- Number: 3 Section: All Type: Editorial Priority: High Problem: Internal references in this document are usually links, and they usually have a section number and name attached to them. Likely this was to facilitate reading a printed version and following the references. The problem with this is that, since the printed version does not have proper page headers and footers that show section identifiers, it is actually very hard to follow the references. Recommended Solution: Remove the explicit section numbers and names (unless they are the actual link). Rely upon the tool html2ps to generate a postscript and pdf version of the specification suitable for printing. [Yes, I volunteer to assist with this effort. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic108 ----- Number: 4 Section: All Paragraph: All Type: Editorial Priority: Low Problem: In many cases where an enumerated list is presented in prose, it takes the form "item1, item2, item3 and item4." This is more properly presented as "item1, item2, item3, and item4." Recommended Solution: Fix the prose lists so they are consistent. XForms WG Response: Editorial issue fixed. ----- Number: 5 Section: All Paragraph: All Type: Technical Priority: High Problem: When elements, their content models, and their attribute lists are presented formally, this document uses a syntax defined in section 1.4. That syntax may be something that is used in other specifications, but the HTML Working group has adopted a different format. For consistency with the XHTML specifications, this document should adopt those conventions. Recommended Solution: Convert the XML syntax representations of the elements to the abstract module notation as defined in XHTML Modularization 1.0. [Yes, I volunteer to assist with this.] The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic109 ----- Number: 6 Section: All Paragraph: All Type: technical Priority: high Problem: This specification relies upon XLink. I thought that the HTML working group determined that we didn't like XLink. If Xlink functionality is sufficient for this specification, I guess that is okay. But it is inconsistent. Recommended Solution: I would prefer that this specification rely upon the same mechanism as that of XHTML 2.0 for expressing linkimg semantics. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic110 ----- Number: 7 Section: all Paragraph: all Type: technical Priority: high Problem: The spec does not indicate which attributes are required. Recommended Solution: Ensure that in each element definition, any required attributes are clearly defined. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic111 ----- Number: 8 Section: Abstract Paragraph: 1 Type: Editorial Priority: Low Problem: The term "Forms for the Web" seems a little colloquial or something. If it was a long-consdered pithy marking phrase or something, great. If not, we sort of need one. Something like "XForms - it's not your father's <form> element". :-) Recommended Solution: I don't really have one, but good marketing is as important as a good specification - probably more important. Someone should think about this. XForms WG Response: Micah agrees to think about it ;-). ----- Number: 9 Section: 2.1 Paragraph: External schema augmentation Type: Editorial Priority: low Problem: The first sentence is missing a word. Recommended Solution: Change "This enables the XForms author go beyond..." to "This enables the XForms author to go beyond..." XForms WG Response: Editorial issue fixed. ----- Number: 10 Section: Section 2.2 Paragraph: last Type: editorial Priority: low Problem: The last sentence is kind of awkward. I would rephrase it as Recommended Solution: "In contrast, XForms greatly improves the expressive capabilities of electronic forms." XForms WG Response: Editorial issue fixed. ----- Number: 11 Section: 2.3 Paragraph: first PRE block Type: editorial/technical Priority: medium Problem: The URL uses examples.com. This should be example.com Recommended Solution: Change "examples.com" to "example.com". ----- Number: 12 Section: 2.5 Paragraph: 1 Type: editorial Priority: medium Problem: This paragraph is awkward. Recommended Solution: Rephrase as "XForms allows data to be checked for validity on the client. In classic HTML forms, constraints like the following could only be enforced through the addition of sophisticated scripts:" Or something like that, if that is what you were trying to say. ----- Number: 13 Section: 2.6 Paragraph: 2 Type: editorial Priority: medium Problem: This paragraph is awkward. Recommended Solution: Rephrase as "In addition, form controls need to identify the model element that contains the instance data to which they are bound. This is done via a model attribute, in conjunction with the ref attribute. The default value for the model attribute is the first model element (in document order)." Or something like that. ----- Number: 14 Section: 3.2 Paragraph: 1 Type: editorial Priority: low Problem: The phase "see the schema for XForms" in the middle of this paragraph is not really necessary, and makes no sense if that phrase is considered a dependent clause. Recommended Solution: Change to read "Every element defined in this specification declares attribute id or type xsd:ID. Such elements are referencable via attributes of type xsd:idref" and ensure that xsd:ID and xsd:idref are links to the definition of those types elsewhere in the document. XForms WG Response: Editorial issue fixed. ----- Number: 15 Section: 3.2 Paragraph: 3 Type: editorial Priority: medium Problem: The Schema for XForms should be a link. Recommended Solution: Make it one. ----- Number: 16 Section: 3.3 Paragraph: 1 Type: technical Priority: critical Problem: This paragraph reads "The content of element model is typically not rendered." This is a throw away phrase. We need to assert the behavior of this element w.r.t. presentation. Recommended Solution: Change to read "The default behavior for the content of element model is that it is not rendered." Alternately, and better in my opinion, "The content of element model must not be rendered." Otherwise a conforming implementation could be displaying the model, and we all know we don't want that. Ever. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic112 ----- Number: 17 Section: 3.6 Paragraph: last Type: editorial Priority: high Problem: There is no reference to SOAP where a SOAP envelope is mentioned. Recommended Solution: Insert a reference to [SOAP], with a link into the informative references. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic113 ----- Number: 18 Section: 3.8.1 Paragraph: 2 Type: technical Priority: high Problem: The prose says that the example is unusual because there is a default xlink:type attribute. I am sure there is, in the schema. But we have not really been introduced to the schema yet, and the syntax definition in section 3.5 does not specify the default xlink:type setting for the xlink:href attribute. Recommended Solution: Ensure that whenever there is an xlink attribute presented in a syntax definition, its default type is explicitly specified (if appropriate). Add more descriptive text here about that attribute's importance. Provide a link back to section 3.5. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic114 ----- Number: 19 Section: 4.2.5 Paragraph: last Type: technical Priority: high Problem: This section introduces two important concepts with no explanation: xforms without models, and multiply rooted instances data. Neither had been discussed before. These are critical and difficult concepts, and need to be defined and discussed before they are used. Recommended Solution: Add a definition of "multiply rooted" in the glossary/terms section, and describe the behavior when there is no model element in section 3.3. Note that in that section, it indicates that there may be one or more model elements, so the absence of a model element is confusing even to me. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic115 ----- Number: 20 Section: 4.3.1 Paragraph: last Type: technical Priority: high Problem: According to the text, I am required to use scripting to bind events to the instance data. However, I think that if the instance data is predeclared, and if that data has "id" attributes, it should be possible to use XML Events to bind events to specific instances or to whole collections of instance data. Recommended Solution: Make it clear that XML Events can be used in addition to scripts. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic116 ----- Number: 21 Section: 4.3.2 Paragraph: list items 1 through 4 Type: technical Priority: high Problem: This document introduces a navIndex attribute, using it in favor of the tabindex attribute that is used in XHTML. That's fine, but it is not clear how the tabbing/navigation order of an XHTML document would intersect with that of an embedded form. Recommended Solution: Clarify the relationship of navIndex to tabindex - here or in an appendix. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic117 ----- Number: 22 Section: 4.3.5 Paragraph: 2 (example) Type: technical Priority: high Problem: The example describes a situation where input validation is done. This section (and others such as 4.3.12) implies that if an input field is invalid (violates constraints?), an error would be displayed and the user required to satisfy the constraints of the field. This means that, for example, if I start to enter my credit card number, then decide I want to fill in some other field first, I can't. Recommended Solution: Don't have one. I am hoping you will tell me I am wrong. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic118 ----- Number: 23 Section: 4.3.5 Paragraph: 3 Type: editorial Priority: low Problem: A word is missing. Recommended Solution: Change "... are expected optimize processing..." to "...are expected to optimize processing..." XForms WG Response: Editorial issue fixed. ----- Number: 24 Section: 4.3.17 Paragraph: list items 1 & 2 Type: technical Priority: medium Problem: These are good assertions, but they are untestable. Recommended Solution: None, really. I just wanted to be sure that you meant to have untestable assertions as requirements for implementors. ----- Number: 25 Section: 4.3.17 Paragraph: list item 4 Type: editorial Priority: medium Problem: Why is MUST in uppercase in this paragraph? Recommended Solution: Change MUST to must. ----- Number: 26 Section: 4.4.1 Paragraph: list item 1 Type: editorial Priority: medium Problem: The second sentence doesn't make sense. Recommended Solution: Change it to read "This node and all child nodes are used in the remainder of the submit process." ----- Number: 27 Section: 4.4.1 Paragraph: list item 2 Type: technical Priority: high Problem: This item indicates that invalid instance data encountered during the submit process stops submit processing. It does not indicate what (if any) events are raised when this happens, or how errors are manifested to the user. Recommended Solution: Make it clear what happens when submit processing stops. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic119 ----- Number: 28 Section: 4.4.1 Paragraph: list item 3 Type: editorial Priority: low Problem: THe second sentence is awkward. Recommended Solution: Change to read "Nodes that have associated relevant constraints that evaluate to false are not serialized." XForms WG Response: Editorial issue fixed. ----- Number: 29 Section: 4.4.2 Paragraph: 3 Type: editorial Priority: medium Problem: Wrong word. Recommended Solution: Change "expresses" to "express". ----- Number: 30 Section: 4.4.2 Paragraph: all Type: technical Priority: high Problem: This section uses the term urlencoded, but that term is not defined. Recommended Solution: Define the term. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic120 ----- Number: 31 Section: 4.4.4 Paragraph: list item 2 Type: editorial Priority: low Problem: Wrong word. Recommended Solution: Change "an the above" to "the above" - I think. This whole item reads very strangely. XForms WG Response: Editorial issue fixed. ----- Number: 32 Section: 4.5 Paragraph: all Type: technical Priority: high Problem: The items in this section talk about default error handling, but that is not defined. Recommended Solution: Define default error handling. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic122 ----- Number: 33 Section: 6.1.4 Paragraph: user interaction table Type: technical Priority: high Problem: The false items use "should". I believe these are "must" constraints. Recommended Solution: Change "should" to "must". The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic123 ----- Number: 34 Section: 6.2.1 Paragraph: list item 4 Type: editorial Priority: low Problem: Missing quotes. Recommended Solution: Put quotes around the attribute value. XForms WG Response: Editorial issue fixed. ----- Number: 35 Section: 6.3.2 Paragraph: example text Type: technical Priority: high Problem: I don't think this example actually does what it is supposed to. The union doesn't seem to be a combination of the enumerated set and an "other" item. Recommended Solution: Fix the example or show me that I am wrong. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic124 ----- Number: 36 Section: 6.4.2 Paragraph: list item 1 Type: editorial Priority: low Problem: The formatting of the example seems wrong. Recommended Solution: Fix the indentation. XForms WG Response: Editorial issue fixed. ----- Number: 37 Section: 6.4.2 Paragraph: last Type: technical Priority: high Problem: This section indicates that processing can terminate with a fatal error. It does not, however, define what that error is, or what event might be raised. Recommended Solution: Describe what it means to terminate with a fatal error. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic125 ----- Number: 38 Section: 7.4.2 Paragraph: all Type: technical Priority: medium Problem: Many of the items in this section talk about NaN. On platforms that do not support IEEE Floating Point, is there a concept of Nan? Recommended Solution: If there is, do nothing. If not, let's describe what happens on platforms without IEEE Floating Point. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic126 ----- Number: 39 Section: 7.4.2.5 Paragraph: last Type: technical Priority: High Problem: This section indicates that an error is thrown, but does not indicate what type of error. Recommended Solution: Define the error. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic127 ----- Number: 40 Section: 7.4.4 Paragraph: last Type: editorial Priority: low Problem: Missing word. Recommended Solution: Change "...XForms processors detect the..." to "...XForms processors to detect the...". XForms WG Response: Editorial issue fixed. ----- Number: 41 Section: 8 Paragraph: all Type: technical Priority: medium Problem: Throughout this section you indicate that form controls can by styled by using CSS in conjunction with the class attribute. I believe that you can also use the id attribute. Recommended Solution: If I am correct, add id to the discussion of styling form controls. ----- Number: 42 Section: 8.2 Paragraph: last Type: technical Priority: high Problem: The example has a caption element, but it does not show up in the sample output. Recommended Solution: Fix the example source or the example output. ----- Number: 43 Section: 8.4 Paragraph: 1 Type: technical Priority: medium Problem: The concept of "display:inline" has not been defined in this spec. Recommended Solution: Define it by reference to CSS or remove the text about layout (it isn't really needed here). ----- Number: 44 Section: 8.5 Paragraph: 1 Type: editorial Priority: medium Problem: The first sentence is a little colloquial. Recommended Solution: Change it to "This form control enables uploading of files from the local file system, as well as..." ----- Number: 45 Section: 8.5 Paragraph: Implementation requirements Type: editorial Priority: medium Problem: Wrong word. Recommended Solution: Change "Implementations may provide proprietary implementations..." to "Implementations may provide proprietary interfaces..." ----- Number: 46 Section: 8.6 Paragraph: 3 Type: editorial Priority: medium Problem: The whole paragraph is really awkward. Recommended Solution: Rewrite it so it is more than one sentence. ----- Number: 47 Section: 8.7 Paragraph: 1 Type: editorial Priority: low Problem: The phrasing of the whole second sentence is a little weird. Recommended Solution: Change to read "This form control may also be used to construct other custom form controls." XForms WG Response: Editorial issue fixed. ----- Number: 48 Section: 8.9 Paragraph: 3 Type: technical Priority: high Problem: This section seems to imply that an item of a selection list must always be selected. I think there should be a way have a list with nothing selected. Recommended Solution: Clarify how a list can have no items selected. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic126 ----- Number: 49 Section: 8.9 Paragraph: 5 & 6 Type: editorial Priority: high Problem: These paragraphs seem to be saying the same thing in different ways. Recommended Solution: Consolidate them. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic129 ----- Number: 50 Section: 8.12.3 Paragraph: last Type: technical Priority: high Problem: This says it is an error if... Is this just a usage constraint, or is there an actial error event that is raised when these conditions are met? Recommended Solution: Clarify this. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic130 ----- Number: 51 Section: 8.12.4.4 Paragraph: last Type: editorial Priority: medium Problem: extra word. Recommended Solution: Change "exist at in instance" to "exist in instance". ----- Number: 52 Section: 9.3.1 Paragraph: list item 4 Type: technical Priority: high Problem: This item indicates that an error is signalled and processing stops. Is there an actual error event? And what does it mean that processing stops? Recommended Solution: Clarify this. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic131 ----- Number: 53 Section: 9.3.1 Paragraph: last - 1 Type: editorial Priority: low Problem: Wrong number. Recommended Solution: Change "...node-set represent a homogenous..." to "...node-set represents a homogenous..." The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic172 XForms WG Response: Editorial issue fixed. ----- Number: 54 Section: 10.6 Paragraph: 1 Type: technical Priority: high Problem: The treatment of both items being present is inconsistent with the way multiple items are treated in other elements. Recommended Solution: Change so that the xlink:href attribute takes precedence. ----- Number: 55 Section: 10.6 Paragraph: all Type: technical Priority: high Problem: The spec currently uses the term "application-specific". I prefer the term "implementation-defined", as that requires the application to define how it behaves. Recommended Solution: Change "application-specific" to "implementation-defined". The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic173 ----- Number: 56 Section: 10.7 Paragraph: last Type: technical Priority: high Problem: This section shows that you can set the value of a node to the smpty string. Is there a way to set the value to null or undef? Recommended Solution: None. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic174 ----- Number: 57 Section: 10.14 Paragraph: 1 Type: technical Priority: medium Problem: This section seems to imply that an ev:handler value must be a script. I think that xml events permits handlers to be non-scripted. Recommended Solution: If I am right, change the text so that it does not imply that the event handlers must be scripts. ----- Number: 58 Section: 11.1 Paragraph: all Type: technical Priority: medium Problem: This conformance requirements say "should" when hey should really say "must". Recommended Solution: Change "should" to "must". ----- Number: 59 Section: B Paragraph: XHTML 1.0 Type: tecnical Priority: high Problem: I think that this should reference XHTML 1.1, not 1.0. Recommended Solution: Change the reference. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic175 ----- Number: 60 Section: C.1 Paragraph: 2 Type: technical Priority: high Problem: This section also indicates that there can be a fatal exception. Recommended Solution: Clarify what really happens. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic176 ----- Number: 61 Section: E.1 Paragraph: example Type: editorial Priority: high Problem: When you imported the text, you neglected to escape the dollarsigns. That means that the CVS Id at the top became the Id of the spec, instead of the Id of the example. Recommended Solution: Escape dollarsigns when importing examples into the document. The discussion and resolution is archived at: http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic177 -----
xxxxxx
The discussion and resolution is archived at:
Subject:
As promised, the comments of the CSS WG on the XForms 1.0 draft
(http://www.w3.org/TR/2002/WD-xforms-20020118):
a) The criteria to exit from CR are too weak.
We suggest the criteria of the Selectors CR[1], with the addition
(which we unfortunately forgot to add to the Selectors criteria) that
features *may* be dropped in order to exit CR status. ("May" indicates
that this is a case by case decision for each feature: sometimes it is
better to drop the feature, sometimes to extend the CR period.)
[1] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current
b) The "selectMany" element should have attributes for specifying the
minimum and maximum number of items to select.
Selections like "select between 1 and 5 of these 30" appear frequently
in practice. We realize that this makes "selectOne" redundant, but
that element can be kept as a convenience for authors.
c) The choice between "radiobutton" and "checkbox" should be made
automatically based on the number of items to select.
How the controls actually looks is a style question, but the semantics
of "radio" is that there is exactly one item selected from the set,
while "checkbox" means each item can be on or off independently. We
ask to drop "radiobutton" and "checkbox" and instead introduce a
single keyword, that means either, depending on whether min = max = 1
or not. Some suggestions: "togglebutton", "toggle", "togglebox",
"toggler".
d) HTTP GET should not be deprecated.
The semantics of GET and POST are different. As the HTTP spec says,
GET is idempotent, POST is not.
e) We suggest changing "should" to "may" in section 8.1, where it says
that the UA "should" select the best UI widget for each data type.
The type is insufficient to really do a good job with picking an
appropriate widget. A derived type doesn't necessarily require the
same interface as its superclass. And even a Date may require
different interfaces, based on whether, e.g., the expected date is in
this month (a calendar might work), or long in the past (a text field
might be easier), or part of a set of similar dates (a set of text
fields with autocompletion).
f) We think there are problems with the inputMode attribute, but we
defer to the I18N group.
g) All elements that are intended to be displayed should have a
"style" attribute.
For various reasons (cut & paste of elements, experiments, local
overrides, consistency with SVG and HTML...), the "style" attribute is
a good thing. The fact that the "ideal" style sheet is an external
style sheet is not enough reason to disallow the attribute.
h) The "caption" element should be called "label" (8.12.4.1)
A caption is typically something associated with a table or a figure
and it is usually displayed below the thing it describes. The right
name for the element in XForms seems to be "label", which is also what
HTML calls it.
i) The "cursor" (7.4.3.5) should be called something else.
A "cursor" will be understood by most people as the mouse pointer or
the insertion point in a text editor. Indeed, CSS uses 'cursor' as a
property to set the shape of the mouse pointer. To avoid confusion, we
suggest a name such as "currentElement".
j) We suggest an informative section describing a "pseudo-element" to
allow a style sheet to address the actual input widget.
When styling the "input" element, one can select the caption (label),
the hint and the container that holds all of those, but not the actual
input widget. To allow styling of that input field, we suggest that
the XForms draft adds an informative section that introduces a
"pseudo-element" (a CSS term) that represents that object, which
exists on the screen but not in the source document. The name could be
'::input-value'.
The section should explain that the '::input-value' is a part of the
"input" element that conceptually comes at the end of the element. In
CSS, we typically use a "fictional tag sequence" to describe the tree
as it is seen by a renderer:
<input><caption>...</caption><input::input-value/></input>
An example of its use would be the following, which creates (a row in)
a table with two columns and puts the label in the first column and
the input field in the second:
input { display: table-row }
input label { display: table-cell }
input::input-value { display: table-cell }
It can be further styled with colors, backgrounds, borders, margins,
etc.
For the CSS WG, issue 81.1-
Bert
See responses in Message 55, and those below. Additionally here:
j) We will add an informative note.
The discussion and resolution is archived at:
issue 81-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic72
issue 81.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic73
issue 81.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic74
issue 81.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic75
issue 81.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic76
issue 81.5-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic77
issue 81.6-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic78
issue 81.7-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic79
issue 81.8-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic80
issue 81.9-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic81
issue 81.10-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic82
issue 81.1-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic152
issue 81.2-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic153
issue 81.3-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic154
issue 81.4-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic155
issue 81.5-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic156
issue 81.6-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic157
issue 81.7-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic158
issue 81.8-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic159
issue 81.9-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic160
issue 81.10-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic161
issue 81.10-
http://www.w3.org/MarkUp/Forms/Group/2002/f2f-Cannes/minutes.html#topic164
Subject:
Hi, XForms is presented as the successor of HTML forms. It is supposed to become the next solution for forms on the web. A requirement is that there be transition path from HTML forms to XForms. Because of this there are at least two legacy links in the specification: HTML and HTTP. I wonder whether this state of affairs is not going to restrain the evolution of XForms and if the support of this legacy is worthwhile. What would be a situation in which legacy could interfere with an XForms-based solution? For example, a form created with XForms could produce form data which can be processed with an existing active web-component. Such a form would have to be flat for obvious reasons. I think it is unlikely that XForms would be used for this for two reasons. First, something would have to be developed anyway to produce the new form, so providing a new form data processor too wouldn't be a real problem. Second, one could stick to HTML forms for this, because the only added value of XForms left in this case is the separation of form content and presentation. However, this can also be achieved with a naked HTML form and a style sheet. The most important reason for using XForms is that it can handle structure. Because of this it will be possible to have master-detail relationships in forms. In such a case, using a serialisation format which can be understood by legacy systems doesn't make sense, because they would only understand the encoding but not the content. I therefore think text/xml (or derived types) is the only relevant format as a minimal requirement for an implementation. The reason why we have this legacy is the strong web-orientation of XForms. In my opinion the specification would have more value if it didn't refer to the web directly, but only specified, in isolation, what is required if it is used in a web context. XForms covers much more than browsers and web-servers. It is the most interesting way to create forms applications in general. XForms could be implemented, for example, as a GUI component. Such an implementation could expose the whole form as a DOM tree. The application using the component could then use DOM Events to interact with it. This means that not even the submission method is fixed. The submitted content, however, is. The application could register a handler for the submit event and use another protocol than HTTP for the actual submission. I think the central part of the specification should only cover behaviour and content. Separate sections could explain how the data, which is to be submitted, is serialised in the various contexts. Obvious contexts are plain HTTP, SOAP over any protocol such as HTTP, SMTP, etc., and even IIOP. In the latter case the action attribute of submitinfo could be a name from a CORBA name space or a JNDI name of an EJB. These are just examples. Regards, Werner.
Original resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Sent 2002aug02: http://lists.w3.org/Archives/Public/www-forms-editor/2002Aug/0000.html.
Accepted 2002aug05: http://lists.w3.org/Archives/Public/www-forms-editor/2002Aug/0003.html
Dear Werner Donné: Your comments [1] on the www-forms@w3.org mailing list about the XForms Last Call Working draft [2] were forwarded to the XForms Last Call mailing list [3] have been captured as Last Call Issue 82. Please respond to state whether you agree with resolution below. Thank you, Leigh L. Klotz, Jr. -------------------------------- XForms WG Resolution: Please refer to the XForms Schema recently published [4] for the following discussion. I. In order to help the web transition, we have included support for existing HTML and HTTP features as requested by public feedback. II. The model submission element in not required by the XForms Schema, and the xforms-submit event is available for event-based processing of submission. III. XForms provides read/write for DOM access through IDL interface definitions, though how these interfaces are exposed to the user agent is implementation specific (i.e., ECMAScript functions, etc. are not defined in the XForms specification). IV. We moved the details of serialization and submission section a new section, and now use the submission action URI and the submission method attribute to control the serialization and submission of the instance data. The method is defined as a union of QNames, with the XForms namespace list being fixed and the other namespaces being open for extensions such as you descibe above. The mediaType and mediaTypeExtension attributes are no longer used. [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0155.html [2] http://www.w3.org/TR/2002/WD-xforms-20020118/ [3] http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html [4] http://lists.w3.org/Archives/Public/www-forms/2002Jul/0045.html
The discussion and resolution is archived at: http://lists.w3.org/Archives/Member/w3c-forms/2002JulSep/att-0176/01-2002jul26-review.html#ACTION7.
Subject:
Hi, In chapter 8.11.3, it is stated that the available choices are determined at run-time. Does it mean that these choices can be changed after initialization? If so, if the value of a selected itemset is changed, what should happen ? If it's a closed selection, I suppose the instance data bound to the control should be changed accordingly. If it's an open selection, should the behaviour be the same, or should the old itemset value become the new "free entry" text ? Thanks, Jérôme
Original resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Resolved (see issue 28)
The discussion and resolution is archived at:
Subject:
Micah Dubinko wrote: > > For forms, the main advantage of GET is that it's currently deployed on a > zillion browsers and everyone understands how it works. I'm sure we're in agreement, but I want to make the point that GET had advantages even when it was invented, before there was a legacy issue. GET allows forms to be a user interface to complicated information repositories, like the Google database, Yahoo's personals database, Amazon's book database, etc. Before the web was about e-commerce, it was about exposing database data across organizational boundaries in a standardized way. POST does a poor job of this because the resulting query results cannot be linked. Of course there are all sorts of server-side tricks that you can do to trick the browser into doing a GET after a POST but this is more difficult to code and has some client-side UI problems. >... > clicking the submit control would generate a URI like > http://www.google.com/search?q=foo Does this also work for forms with multiple fields? In particular, I note that HTML forms tend to generate ampersands (yes, there are issues with that choice of character) whereas XForms generate semicolons. I'm all for moving towards semi-colons but shouldn't this be a *choice*? I'd suggest that there needs to be a way to generage "application/x-www-form-urlencoded" in a manner compatible with HTML. There is an open issue about this so I look forward to it resolution. Paul Prescod
Original resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Resolved
Sent 2002aug02 http://lists.w3.org/Archives/Public/www-forms-editor/2002Aug/0001.html
Accepted 2002aug02 http://lists.w3.org/Archives/Public/www-forms-editor/2002Aug/0002.html
Dear Paul Prescod: Your comments [1] on the www-forms@w3.org mailing list about the XForms Last Call Working draft [2] were forwarded to the XForms Last Call mailing list [3] have been captured as Last Call Issue 84. Please respond to state whether you agree with resolution below. Thank you, Leigh L. Klotz, Jr. -------------------------------- XForms WG Resolution: Please refer to the XForms Schema recently published [4] for the following discussion. I. GET is no longer deprecated in our next upcoming public draft. We will include references to [5] and [6]. II. The default for XForms for multiple fields with HTTP GET is to separate with semicolon. Theattribute allows the use of either ampersand or semicolon. [1] http://lists.w3.org/Archives/Public/www-forms/2002Jan/0155.html [2] http://www.w3.org/TR/2002/WD-xforms-20020118/ [3] http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html [4] http://lists.w3.org/Archives/Public/www-forms/2002Jul/0045.html [5] http://www.w3.org/2001/tag/doc/get7 [6] RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt)
The discussion and resolution is archived at: http://lists.w3.org/Archives/Member/w3c-forms/2002JulSep/att-0176/01-2002jul26-review.html#ACTION8.
Subject:
Greetings all, I just had one question about where dynamic data should be generated for things like dropdown lists. After reading the xForms spec, I think that the data is expected to be generated dynamically on the server and the listdata values are hardcoded into the xForm definition. Is there any way of defining an external client side data source for dropdown list to prevent server side processing, or was that considered and discarded? Thanks very much, Dave Johnson
resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Hello David,
The www-forms-editor list is specifically for Last Call comments. The www-forms list is for general discussion. To answer your original question: http://lists.w3.org/Archives/Public/www-forms/2002Jan/0172.html >I think that the data is expected to be generated dynamically on the server and the listdata values are hardcoded into the xForm definition. That's one way to do it, but not the only way. The <itemset> tag allows a list to be populated at run-time, from instance data (which can come from any URI). >Is there any way of defining an external client side data source for dropdown list to prevent server side processing, or was that considered and discarded? Well, XForms doesn't define anything about data sources (understandably, I hope!). We do define the interface: XML instance data. Any source, client or server, that can make data available as XML addressed by a URI could be used. For interoperability, we are requiring HTTP support ("http://" URIs), with other schemes (e.g. "file://") possible and expected.
I hope this answers your question.
The discussion and resolution is archived at:
Subject:
Hi, chapter 6.4.1 states that "attributes on element bind encode XForms constraints to be applied to each node in the node-set.", whereas chapter 7.3 point 3 states that the context node for this constraints is only the *first* node of the node-set. Isn't it a contradiction in terms? Regards, Jérôme Nègre
resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Thank you for noticing this editorial mistake. > We have fixed it for the upcoming publication of XForms specification.
The discussion and resolution is archived at:
Subject:
Can someone help me understand 11.2.1 "Conforming XForms Processors"?
The first bullet says
All XForms Processors must support the required portions of the specifications normatively listed as references (B References). But "B References" doesn't list anything about XForms.
The next two bullets in 11.2.1 seem to refer to a list which I interpret at the list in the first bullet. Nothing on that list is labeled "Basic".
Thanks, John.
resent from www-forms@w3.org (see http://lists.w3.org/Archives/Public/www-forms-editor/2002Feb/0106.html)
Thank you for noticing this.
We agree.
We have fixed it for the upcoming publication of XForms specification.
The discussion and resolution is archived at:
Thierry MICHEL (tmichel@w3.org)
Last Updated:$Date: 2002/08/05 19:42:39 $