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

Hi Mark,

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

Modularization is not *the* key, but *a* key.  And in fact I think the WG 
has shown that it agrees by basically spending the entire face to face on 
it.

But it's not the only thing.  We're executing on a 3-fold strategy for 
adoption. 

First, defeat the cross-browser availability obstacle.  We're doing that 
with the Ubiquity XForms processor, which gets around the problem of 
needing the browser vendors to adopt our technology in order for our 
technology to be available on their browsers.

Second, defeat the rip-and-replace obstacle.  This is being done in part 
by modularization, as it allows incremental adoption rather than 
monolithic adoption.  It is also being done in part by FormsA / WebFormsA. 
 By taking an attribute-based approach, we are able to apply the most 
important concepts from XForms to the larger class of HTML documents, 
rather than requiring an overall of a document before it can be ready for 
XForms.  Moreover, the fact that we are able to align the use of these 
attributes with the XForms processing model means that we are able to 
scale up to using modules containing XForms elements when needed.

Third, defeat the perceived complexity obstacle.  This is being done in 
part by modularization and in part by FormsA / WebFormsA.  The 
attribute-based technique is an answer to the basic complaint that simple 
things should be simple to do.  If I just want some small feature, why 
can't I just have an attribute for it?  More generally, how easy is it to 
create a reasonably simple application like a purchase order?  If you 
check out what I did in the latest draft, you'll see that we get all the 
way home with the attribute system. More complex apps will require the 
additional complex features of full XForms, but you can do useful things 
before you get there with a simple and easy on-ramp that is 
architecturally aligned with scaling up to full XForms.

> But I'm afraid I disagree that it's our job to heal divisions.

I didn't say it was our job, directly.  But you still have to look back at 
why the rift happened.  It happened because we were not executing on all 
three of the above points.  The W3M wants the rift mended because they 
think the HTML WG membership has a set of legitimate points that need to 
be addressed, and the rift exists because the points were not being 
addressed for a very long time.  All of the work we are doing now is 
addressing those points. 

We may do the work and still not be able to mend the rift, but I think you 
are saying that then at least we have done our job according to our 
charter.  True, but the point of doing the work is so that it *will* be 
adopted and in particular that it will be adopted by those who currently 
go out to the world and say that our work is not relevant to the future of 
the web.  It is relevant to the future of the web, but the onus is on us 
to demonstrate this to be the case.

What put the onus there?  The charter did, which means the W3C did.  The 
vote of the W3C to charter our group is based on the charter document. The 
expectation is that we will execute on the charter.  Our charter calls for 
us to work with the HTML WG to come up with a blend of XForms and Web 
Forms 2.0.  This gets us back to the reason why that charter requirement 
exists, which is the same reason as why the rift happened.  This is why we 
have to do well at both technical design and positioning and promotion.

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

This isn't about being "too political".  It isn't even about being 
political.  The politics, in fact, already happened.

> If we have a solution that we think is right, then we should pursue
> it, and try to encourage its widespread adoption. 

We do, and we should.  We have a great thing called XForms.  We now have a 
really cool "XForms accelerator" that increases the consumability of 
XForms by reducing the time to benefit and increasing the breadth of 
platforms and documents where said benefit can be realized.  Now we should 
encourage its widespread adoption by building it into Ubiquity XForms, by 
having the savvy to call it what it is (WebFormsA), and by actively 
selling it to the HTML WG as the merge point of XForms and Web Forms 2.0.  
That's the win-win.

> I don't believe we should try to second-guess what might or might not 
make people support it.

Again, please refer to the charter.  We do not have to guess, much less 
second guess.  We have been told in very clear terms that we need to make 
some improvements, and it has been demonstrated to us that if we don't 
improve, then someone else will make the improvements for us. 

On the other hand, a major reason we got rechartered is that I wrote a lot 
of letters to a lot of people explaining how it was indeed possible to 
bridge the rift that had formed by making something that had the key 
properties of Web Forms 2.0 but which projected onto the XForms processing 
model.  The FormsA / WebFormsA spec is the detailed version of that 
argument, proving that the merge is technically feasible (which many did 
not believe). Now that technical feasibility is at hand, we need to do 
what it takes to finish the job of ensuring that the work is adopted by 
HTML WG, rather than having them continue with a design that does not 
accommodate for the XForms processing model and therefore does not 
reasonably allow incremental adoption of the modules we are creating.

John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Mark Birbeck" <mark.birbeck@webbackplane.com>
To:
John Boyer/CanWest/IBM@IBMCA
Cc:
public-forms@w3.org, "Charles F Wiecha" <wiecha@us.ibm.com>
Date:
10/27/2008 03:58 PM
Subject:
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)