Re: A forms-lite straw man

Hi Matthew,

> The |version| attribute is deprecated... Haven't seen it used in the 
wild.

1) So?!?  That it is not in current use doesn't mean it cannot be 
reactivated in order to help control updates to the language.  If 
standard-compliant processors agree to only make features available based 
on version, then anyone attempting to use new features will notice right 
soon that they aren't working and quickly learn to add the version 
attribute to get at the new features.

2) So?!? My point is not so literal and concrete as you are reading it. 
The specific implementation does not concern me.  What concerns me is 
proving that there exists at least one easy method to overcome the 
problems people keep raising.  Remember, obstacles are what you see when 
you take your eyes off the goal.  If you don't like the version attribute, 
then how about noting the namespace attribute?  How about simply using an 
XML reader until a problem is noted?  How about using a tag soup reader 
until a new feature is noticed?  How about you propose some other solution 
you like better now that we know that there is at least one solution to 
the problem?

> Explain how you do efficient incremental rendering.

Already did.  The original solution I described offers the ability to 
detect what's going on as soon as the first start tag has been read. 
Explain why that *doesn't* work.

> You can't rely authors to accurately version content

Quoi?!? If author doesn't version content and as result doesn't access 
feature, then author sure as heck can be relied on to version content. 
What evidence do you have to the contrary?  The only evidence you have is 
that previous browser makers went off and made everything work regardless 
of version number, so the version number was ineffective.  That's 
bootstrapping!

> What's the point of ignoring features, esp. when the content is served 
as text/html?

Because the content type says only what kind of document is coming down 
the pipe, but HTML itself gets to define what HTML means, and if features 
are added by version then they only work when the content says they work.

My own evidence that versioning does indeed work across millions of users 
over 13 years would be my own forms language has undergone the following 
releases: 1.0, 1.1, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 3.0, 3.1, 3.2, 3.3, 4.0 
(start of XML),  4.0.1, 4.1, 4.2, 4.3, 4.4, 4.5, 5.0, 5.1, 6.0, 6.1, 6.2, 
6.3, 6.4, 6.5, and 7.0.  This is why I don't believe people who say it 
can't be done.  I prefer to believe Ian Hickson's favorite quote, which is 
just that it takes longer, which I interpret to mean that the processor 
author has to do a bit more work.  However, versioning really is the only 
*effective* way to cultivate a language over time.

> can't expect them to memorize what version their markup appears in

Why do you think I expect such memorization?  I don't even expect people 
to memorize the tags they're supposed to use.  They use things like ref 
manuals.  They have to create some content at a moment in time, so they 
google the bits they need, it tells them what's available by version, they 
check the version available on the processors they intend to make the 
content available to, and they go about their business.

Query, how is this really different from what you would propose they do 
*without* some kind of versioning?  The content author still has to know 
whether their intended processors support the "version" of HTML they want 
to use, whether or not they have to declare the version number is 
orthogonal to this.  Put another way, what does the 2.0 in Web Forms 2.0 
mean?  It surely seems to mean that IE won't be supporting it any time 
soon, so the content author better have a plan B, such as not using WF2 if 
the processor doesn't support it or *recognizing* that they are using 
features of a different "version" of the language by including some 
additional javascript files or what have you.  The point is that *in some 
syntactic way* the author has to know the version of language from whence 
their features are coming.

> Better to use deprecation in later versions and leverage existing 
structures where appropriate

Sorry, did you just say versions?
I don't mind deprecation, and in fact that's what we're trying to do with 
tag soup.  The effective way to deprecate stuff is to provide incentives 
for content upgrade.  Like new features.

> Conversion is a bad idea

Why?  If someone wants to write simplified syntax for theircontent, then 
let them do that.  But when they finally get to that point when they need 
more depth than single attributes can provide, why not have them run a 
converter so they can get a more formal model, see what their on-the-glass 
design implies, and then they can begin extending the more formal model 
because they have some idea what it means.  Their originating document is 
the Rosetta stone that helps them get started, but it's really gated by 
when they choose to enter the world of more sophisticated content.

> There's no benefit to implementing an "HTML5" if it's not directly 
supported.

By whom?  IE doesn't define the full extent of the web.  If it did, then 
we should say that there's no benefit to WF2, to XForms, to PDF, etc. 
Yikes.

XForms is enabled in all major web browsers through a combination of web 
technologies.  Any upgrades to HTML do require direct implementation, but 
the pool of available implementers of web technologies is much larger than 
just web browser makers.    I sure hope we're not saying that all 
implementers have to go home except those who make an actual web browser, 
because my counter would be that all implementers should go home unless 
they constitute more than 50% of the browser marketshare.  Since I don't 
buy the latter, I obviously don't buy the former either.

> It would make more sense to do an HTML to XHTML conversion on the 
original document before making it available on the server.

Totally agree with you here.  It would have benefits for the author to 
begin to see what has to be done differently.  However, authors of content 
processors really are free to choose what content they are willing to 
recognize and process.  They're also free to decide what data structures 
and algorithms exist in their implementations to effectively respond to 
that content.  A content processor author with an ability to efficienlty 
process XML could well consider JIT conversion of the stream to XML, and a 
content processor author who has an implementation bent around tag soup 
could well consider a reverse conversion of the XML down into something 
the processor can handle more easily.  Either way, those are 
implementation details that we don't seek to standardize, and they are 
details that are independent of deciding what features to make available 
by some sort of versioning scheme.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Matthew Raymond <mattraymond@earthlink.net> 
09/07/2006 08:23 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
public-appformats@w3.org
Subject
Re: A forms-lite straw man






John Boyer wrote:
> So, let's say you receive some text/html, and you read the very first
> tag of it and find that
> 
> 1) the html tag is in the XHTML namespace, and it has a version
> attribute of version="1.2"
> 
> 2) the html tag is in any other namespace, and it has a version
> attribute of version="5"

   The |version| attribute is deprecated in HTML 4.01. I'm not sure I've
ever even seen it used in the wild.

> If these conditions are met, then you just received content that is
> new-style HTML new goodies are at your disposal. If HTML 5, run
> converter to get XHTML 1.2, at which point the complaint against using
> the XForms conceptual model runs out of steam.

   Explain to me how you do efficient incremental rendering and document
conversion at the same time. For that matter, do you honestly expect
user agent vendors to reengineer their HTML support to be little more
than a JIT XHTML converter?

   Furthermore, why can't we use an XHTML 1.1 module for web forms
support instead of creating a new XHTML 1.2?

> If neither of the above conditions are met, then you have HTML 4, so run
> only your old code (ignore tags corresponding to the new features). 

   What's the point in ignoring the features in HTML, especially if the
document has an HTML doctype and is served as "text/html"???

> It should be clear from this that you don't break the old forms.  It
> should also be clear that the issue of old forms is therefore orthogonal
> to the first issue described in this mail involving the interpretation
> of additional attributes on elements like the xforms 'input'.  The
> additional attributes are being discussed to help ease the authoring
> burden of migrating up to new-style HTML, so that there is less work to
> do to get the new features.

   You can't rely on the author to accurately version content, nor can
you expect them to memorize what markup applies to which version. Better
to use deprecation in later versions and leverage existing structures
where appropriate. Conversion, however, is a bad idea. There's no
benefit to implementing an "HTML5" if it's not directly supported. It
would make more sense to do an HTML to XHTML conversion on the original
document before making it available on the server.