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

Well, I do wish you would reconsider your stance here.
You've said that it doesn't matter what we call it as the rationale for 
calling it one thing and not another.

But if it doesn't matter, then let's call it WebFormsA.  Here again are 
the points I've presented in favor of doing so:

1) By closely examining the rough draft specification, one should be able 
to see how closely it is aligned with mapping web forms from HTML4 with 
the architecture of XForms.  This is not an arbitrary mapping for an 
aribtrary host language, though there is some language in the rough draft 
that permits this generalization, as there should be.  But there are 
numerous and specific affordances for backwards compatibility with HTML4, 
and thus it should be clear that this specification is most directly 
targeted at the issue of providing the XForms architecture to forms as 
practiced on the web today.

2) Our charter mission statement calls for us to issue specifications that 
cover forms on the web.  Our deliverables under this charter call for a 
specification that merges the ideation of Web Forms 2.0 with the 
architecture of XForms.   Strategically, this working group must project 
to the web community that it is achieving its charter mission and 
deliverables.  We not only must achieve our objectives, but we must 
clearly communicate that we have done so and let the W3C then sort out any 
namespace conflicts. 

I have already taken as granted the point raised by several, including 
you, that the particular choice of name is unlikely to result in adoption 
by the HTML5 WG.  But this is certainly no reason not to try, and either 
way adoption by the HTML5 WG is a tertiary consideration given the points 
above.  We need to clearly communicate to the much wider web community 
what is the intent of this specification and what is the intent of this 
working group in publishing it.

Please reconsider.  Even an "I don't prefer it but could live with it" 
would expedite the resolution to go to first public working draft with the 
document.

Thank you,
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:
"T.V Raman" <raman@google.com>
To:
mark.birbeck@webbackplane.com
Cc:
John Boyer/CanWest/IBM@IBMCA, public-forms@w3.org, wiecha@us.ibm.com
Date:
10/31/2008 11:45 AM
Subject:
Re: Naming the forms/attribute technology [was Re: Discussion points  for 
"Forms-A"]




1+ to Mark.

Whatever else we might believe, just naming this cat instead of
dog wont get it into the html5 spec.

Mark Birbeck writes:
 > 
 > 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)

-- 
Best Regards,
--raman

Title:  Research Scientist 
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc