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

Received on Friday, 31 October 2008 18:43:51 UTC