Re: Comments on XForms 2

Doug,

Thanks for the feedback. This email is not an official response from
the working group, but I wanted to confirm that the current
in-progress version of the spec is available here:

    Main spec
    https://www.w3.org/MarkUp/Forms/wiki/XForms_2.0

    XPath expression module
    https://www.w3.org/MarkUp/Forms/wiki/XPath_Expressions_Module

I for one absolutely agree that the sentence "XForms are the successor
to HTML forms, and benefit from the lessons learned from HTML forms"
should be removed and maybe replaced. I like you suggestion.

Thanks,

-Erik

On Wed, Aug 5, 2015 at 9:50 AM, Doug Schepers <schepers@w3.org> wrote:
> 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 17:37:02 UTC