Comments on XForms 2

Hi, folks–

Apologies for cross-posting; it wasn't clear which mailing list I should 
use. It's also not clear where the current draft is, so I'm commenting 
on the ones on Steven's site [1] and the XForms wiki [2].

If XForms 2 is going to be picked up as a WD on the standards track 
again, I think it needs some cleanup. I haven't had the time to do a 
thorough review, but I do have a few high-level comments to improve the 
spec.

1) "XForms are the successor to HTML forms, and benefit from the lessons 
learned from HTML forms."

Someone else has already commented on this a year ago [3], but the spec 
still shows that wording; I think it would be confusing for W3C to 
publish a specification that seems to supersede HTML5 in this way. I 
suggest this sentence be removed, or changed to something like:

"XForms was inspired by HTML forms and addresses a broader set of use 
cases using a different model."


2) SVG

"21.3 Survey Using XForms and SVG […] Future versions of the XForms, 
SVG, or other W3C specifications might define more complete rules for 
integrating XForms and SVG".

There is no past, current, or projected work by the SVG WG on 
integrating XForms (though we did have some interest in the early 2000s 
in doing so), nor is there any draft spec by the XForms community to do 
so; thus, it seems misleading to the reader to imply that such work 
might be done.

There are no normative statements in this section; it's not clear what 
the goal of this section is, other than to provide an example.

The example itself is not valid SVG.

It might be best to simply remove this section.

The reference to SVG is using an outdated URL. It should be:
  http://www.w3.org/TR/2011/REC-SVG11-20110816/


3) 10.4.12 The DOMActivate Event

DOMActivate was deprecated in the DOM specs; this should be the "click" 
event. Similarly for other "DOM*" events.


3) HTML5 Compatibility and Accessibility

I'm pleased to see that the spec references HTML5. I think this could be 
expanded to map various features of XForms to equivalent features in HTML5.

As I understand it, XForms was designed in a way that it may fall back 
to HTML forms if XForms is not supported. Looking at the examples, 
though, it wasn't clear that these fallbacks match the parsing model 
defined in HTML5. This has implications for accessibility; for example, 
the first example, in "11.16 The message Element", would produce very 
confusing output, especially to users of screenreaders [4], both in the 
ordering of the input element before the label, and in the erroneous 
error message:

"[input] Enter birthday: isn't a valid birthday"

If I'm wrong about this, and such fallback capability isn't expected, 
this should be made clear in the specification.


4) Relationship to "Browser Web"

Because most specs from W3C relate directly to the "Browser Web", W3C 
should clarify when something is outside that set of expectations. I 
think it would be useful to set the context of implementations, and what 
constraints users can expect when using XForms.

For example, in the introduction or abstract, you might say something like:

"XForms is typically implemented in dedicated XForms clients, rather 
than in Web browsers. At the time of publication, there are no native 
implementations in general-purpose Web browsers, and a JavaScript 
library must be used to emulate support in those clients."


5) Normative language

Throughout the spec, it's not clear what is normative (e.g. MUST, 
SHOULD, MAY, MUST NOT) and what is informative. This makes it much 
harder to get interoperability.

For example, this text in section 3.2.4 (The var element) seems like it 
should be normative, but has no normative prose:

"The var element declares a local variable. A variable is a binding 
between a name and a value. The value of a variable is any sequence of 
nodes and/or atomic values, as defined in XPath Data Model [XDM]."

I'd recommend using RFC2119 keywords consistently throughout (instead of 
words like "is"), and clearly marking sections as normative or 
informative. This is current practice in almost all modern W3C specs.


6) Format

This is a radical suggestion, but it's sincere. I'm a big fan of 
declarative solutions, and I really like many aspects of XForms, but 
because the markup didn't get adoption by browsers, it limits its 
usefulness. I think it might be useful to decouple the XForms model and 
functionality from the markup, and try a more modern approach with 
attributes or even Web Components / Custom Elements. I haven't thought 
through this much, but I suspect if this were refactored to be 
compatible with HTML5, there would be much more uptake.

Obviously, that would be a different specification than XForms 2; but I 
thought I'd mention it. 



[1] 
http://homepages.cwi.nl/~steven/forms/WD-xforms20-20140702/Overview.html#The_function_Element
[2] http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0
[3] https://lists.w3.org/Archives/Public/public-forms/2014Sep/0016.html
[4] 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cinput%20ref%3D%22birthday%22%3E%0A%20%20%20%20%20%3Clabel%3EEnter%20birthday%3A%3C%2Flabel%3E%0A%20%20%20%20%20%3Cmessage%20ev%3Aevent%3D%22xforms-invalid%22%3E%3Coutput%20ref%3D%22.%22%2F%3E%20isn%27t%20a%20valid%20birthday%3C%2Fmessage%3E%0A%3C%2Finput%3E%0A%0A

Regards–
–Doug

Received on Wednesday, 5 August 2015 16:50:36 UTC