Re: Straw poll on name of "streamlined syntax" spec

Hi Nick,

I have to respectfully disagree with you. :)

> Personally I'm a bit struggling with this twofold strategy the strategy of
> making XForms easier and better readable is one that I think is really
> important. Being able to mix HTML Forms with XForms and nicely integrating
> the two, i.e. being able to incrementally add XForms concepts to an HTML
> Forms document is also a nice thing to have.

I believe this is not desirable at a _technical_ level, but at an
_adoption_ level.

The most widely used 'forms language' is almost certainly HTML. So if
you want to get HTML form authors to use XForms, you need a plan that
bridges that gap.

Ajax took off because it bridged the gap; it took existing forms and
documents, and gave them a sprinkling of magic dust. But each library
did it in a non-standard way.


> But I don't know if we need to
> import all attributes and elements from HTML Forns to XForms to accomplish
> this. I even think that this is a 'dangerous' strategy because I think if we
> follow this strategy we are doomed to be always one step behind.

We can't be behind HTML 4, since that's already established.

And we won't be behind HTML 5 until at least 2020. :)


> Because if
> we imported the elements and attributes from HTML forms to XForms an author
> can't use XForms in his document that uses HTML forms + LIBXYZ because
> LIBXYZ has a way to express read-only but doesn't has calculates which he
> wants to use from XForms.

By LIBXYZ, do you mean an Ajax library?

If so, then the problem with this argument is that it therefore means
we can't add *any* new features, since some library somewhere may have
added an attribute or an element to do something useful.

At the end of the day, the W3C is a standards body, and is
sufficiently respected to produce standard attributes and elements.


> It will be even worse if there is a really popular
> language form XYZ that also has form capabilities but lacks some of the
> features we have in XForms. Should we then also import those elements and
> attributes in XForms?

I wouldn't think so.

I'd like to really emphasise that the core of this discussion is that
there are *millions* of people using HTML Forms to create interactive
forms. A large proportion of those find that HTML Forms are not
powerful enough, so they use an Ajax library to augment their mark-up.
They are the people who should be using XForms, and everything I am
saying is about trying to win that audience.

If some future language comes along that comprises people who would
also benefit from using XForms, then certainly we should draw up a
plan to convince them, too.

But today, I believe a key audience is HTML Forms/Ajax programmers.

(I should make clear that I don't mean that this audience is the
*only* audience: most of my company's work is with people creating
intranets, and increasingly, with people embedding formsPlayer into
.NET applications; I would imagine that PicoForms' customers are
people who are deeply into the mobile space; and Orbeon's customers
are probably people who have an aspect of workflow in their
requirements. So whilst we could all do with getting more of these
customers, we don't usually find it hard to win the argument for
XForms with them. But that is not the case with HTML Forms users, and
since there are so many of these, it is worth considering how we
improve the explanation of what XForms offers them.)


> Personally I think it should be much nicer if we have a specification (like
> the one that John has written) that says how you could map all the form
> related concepts of a specific language to XForms and allow the author to
> add 'XForms Core' constructs (elements, attributes) to the markup. If the
> rules are well defined I don't see a problem here. Someone else can do the
> same for HTML Forms + Toolkit XYZ, yet another person can do it for language
> XYZ that has basic native support for forms but lacks some of our features.

I think our experience shows that taking a
'create-a-great-spec-and-the-world-will-come' approach has not worked.


> I'm not sure if someone else is sharing these concerns, but as I see a 'the
> community' that creates dozens of new form related features (controls,
> logic, …) and it would be a shame that they couldn't benefit from our work
> if they would like to do it. If we show them how easy it is to map the
> concepts of HTML forms to XForms and if we manage to publish some XForms 1.2
> modules. The community maybe sees the benefit of using one or more of our
> modules and then just defines how their concepts map onto the XForms ones
> and then they can integrate those modules into their Toolkit.

But it's the enormous audience for HTMLised XForms that we should be
thinking about, in my opinion.

I believe that our considerations for appealing to that audience
should outweigh any considerations of communities that may or may not
yet exist, and may or may not be interested in XForms. We can help
them when they show themselves.

To return to the oft-mentioned example of RDFa; at the moment the only
RDFa spec that exists is XHTML+RDFa, which defines the use of RDFa in
XHTML. But that's ok, because the growing traction in the HTML/XHTML
world is causing other communities to take note, and look at how they
can incorporate RDFa into their languages. (And of course, the RDFa
taskforce is doing everything it can to help.)

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 18 November 2008 16:26:25 UTC