Re: Naming the forms/attribute technology [was Re: Discussion points for "Forms-A"]

Hi John,

> Yes, as soon as your mail arrived, I did the same thing with Google and came
> to the conclusion that the dash has just got to go.

Good. :)


> Regarding whether it is called "FormsA" or "XFormsA" or "WebFormsA", I won't
> focus on the XForms part because it seems unnecessary right now (though I
> can expand on the point Charlie made later if needed).
>
> It really does need to be called "WebFormsA" and not just "FormsA" though.
>
> The reason can be found in our charter here:
>  http://www.w3.org/2007/03/forms-charter.html

You mean the charter _justifies_ it. :)

I don't think it logically follows, any more than any other marketing
moniker might.


> It's really important to read the thing.

Indeed.


>  Our *mission* statement says we
> will "develop specifications to cover forms *on the web*".  There is no
> artificial injection of "web" here.

No-one is saying there is.

But in my opinion there is an artificial reference to the WebForms technology.


> XForms is a technology that does seek to address the issue of forms on the
> web, though its element-based approach has hampered its adoption into
> non-XML documents.

Maybe we should first have a discussion about what exactly has
hampered adoption, then -- I don't think you'll find that it's a lack
of non-XML support.

In fact, the world is increasingly waking up to the idea that
declarative mark-up can be more powerful than raw Ajax.

My argument has always been that adoption has been hampered because we
have not appealed to the Ajax community. But I have never argued that
we should simply be subsumed into it.

I believe XForms is much more powerful than Ajax, but our problem has
always been that we expect people to embrace the entire framework,
rather than letting them have bit-size pieces.


>   The new attribute-based approach is taking a page from
> the likes of RDFa to allow us to apply the technological architecture and
> processing model we have developed originally in XForms into a broader class
> of web forms applications.

Well...the key approach that I've been encouraging us to adopt is not
the 'attribute approach', but the 'modular specification approach'.

Myself, Shanre and Steven took RDFa out of XHTML 2, and made it usable
in its own right. As it happens, it was always conceived of as
something that could be reused in other languages, but still, it
needed to be taken out of XHTML 2 for the rest of the world to think
that it might have some relevance to *today*.

Then we worked with the Semantic Web community to ensure that we had
proper buy-in, and that the specification would be really taken
seriously by their community.

And now it's a full spec, with growing adoption, implementations and support.

We did the same with the Role attribute, which was is now in HTML5 and
finding support in browsers, including IE8.

It's this approach I've been arguing for...the *modularity* of XForms,
not the use of attributes. Of course, a module might just be a few
attributes, just like the @role specification is. But that's not its
key characteristic; the key thing is to give people bit-size pieces of
the XForms philosophy that they can use in their applications, and so
wean them off Ajax.


> It is also a matter of strategic positioning, not a technical issue, that
> drives us here.

You don't need to tell me that. ;)


>  The creative destruction engine is alive and well in the
> W3C, and we have to adapt.  There is no W3C process that describes what is
> currently happening in the W3C, but we're stuck with it anyway.  And what's
> happening is that there has been a major rift that we are attempting to mend
> via this approach.

I agree...and disagree.

You are absolutely right about the W3C not knowing what it is up to at
the moment. But I'm afraid I disagree that it's our job to heal
divisions. Maybe we can do that with a campfire sometime. But in the
meantime I believe we should be writing specifications that we feel
solve real problems, and most importantly, stick to our guns whilst
doing it.


>  We need this thing to get adopted and for progress to be
> made on it with the HTML WG.

I'm afraid I fundamentally disagree that the HTML WG is crucial to
adoption. I was told the same thing, year after year, during the
course of the the RDFa work. But with the recent advancement of RDFa
to a full rec., and its rapidly growing adoption, I feel vindicated in
my view that the HTML WG was not the make-or-break factor for RDFa.

I believe the same for XForms.


>  It needs to become the new thing that
> represents the blending or merging of thinking from XForms and Web Forms 2.
>  For this reason, too, it needs to be called something like "Web Forms A" or
> "WebFormsA".

I'm not following the idea that "it needs to be" something. Why "needs"?

If our starting-point is healing rifts, then I'm afraid this is not
for me. I have enormous respect for Hixie's work, for example, and one
of the reasons that I like what he does, is because he doesn't start
from the position of trying to make friends. :) He starts with what he
wants to get done, and what he believes is right.


> Everyone gets to declare victory on mending the rift at the moment that
> WebFormsA either becomes the new Web Forms 2.0 or becomes the foundation
> upon which the remaining parts of Web Forms 2.0 become based.  At that
> point, we have a forms technology that is architecturally aligned with
> scaling up to the XForms element modules but that is also compatible with a
> softer, easier and more incremental adoption into straight HTML.

I think this is a flawed strategy, and strongly disagree.

I think trying to be too political here simply won't work.

If we have a solution that we think is right, then we should pursue
it, and try to encourage its widespread adoption. I don't believe we
should try to second-guess what might or might not make people support
it.

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 Monday, 27 October 2008 22:59:00 UTC