W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: ISSUE-4: Versioning, namespace URIs and MIME types

From: Sam Ruby <rubys@intertwingly.net>
Date: Thu, 19 Feb 2009 07:58:02 -0500
Message-ID: <499D575A.6070900@intertwingly.net>
To: Ian Hickson <ian@hixie.ch>
CC: Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Ian Hickson wrote:
> On Thu, 19 Feb 2009, Sam Ruby wrote:
>> The only way forward in situations like this is to start over with a new
>> format.
> That's one way forward, but not the only one. HTML5's approach has been to 
> embrace the reality of implementations, and replace previous 
> specifications with a definitive comprehensive set of requirements that 
> matches implementations, including their really strange behaviour (such as 
> "quirks mode" in HTML).
> It's a whole hell of a lot more work than writing a new language from 
> scratch, but it has the advantages of not requiring consumers to support 
> two languages (one of which is effectively undefined) instead of just one, 
> and of not requiring producers to start from scratch when updating to the 
> new technologies (the latter is not a big problem for feed formats, where 
> the feeds typically are generated from source material, but is quite a big 
> deal for original-form formats like HTML, where the content exists only in 
> the form of the "legacy" language).

By snipping in the way you did, you made it appear as it there is a 
disagreement between you and me on this subject, where in fact, there is 
none; at least not at the broad brush level.

By working on HTML you voluntarily accept the constraints that there is 
only so much you can fix in terms of forms (for example).  If one wanted 
to improve this further one would need to (possibly) create entirely new 
elements with new behavior or (and may even be preferably) create an 
entirely new format.

The one thing that doesn't work too well in practice is where a subtle 
change in one or two bytes in one part of a file (generally the top) 
makes a dramatic and visible change to how a completely different part 
of the file is processed.  Increasing the length of the version 
identifier (like has been tried with DOCTYPES) doesn't help.  Moving 
this to someplace invisible (like a HTTP header) doesn't either.

For completeness, I feel compelled to state that none of these 
principles can ever be cleanly applied.  GIF and JPEG can both be used 
to produce similar effects.  For a number of reasons, there was need for 
something more, and PNG was created.  How do browsers tell them apart? 
By looking at the data.  Whether this is a flagrant violation of web 
architecture (Authoritative Metadata[1]) or is an prime example of 
Extending and Versioning Languages[2] is a matter of perspective.

While I said above that we (you and I) agree on broad brush level, there 
are a few details that we need to continue to work through.  The 
A-List-Apart and WordPress crews believe that they are doing XHTML no 
matter how much we might believe differently.  Flagging uses of meta 
charset which do not contradict other sources of metadata as 
non-conformant is an example where something invisible causes something 
else which tools like Venus have a real use case for to be considered 

- Sam Ruby

[1] http://www.w3.org/2001/tag/doc/mime-respect
[2] http://www.w3.org/2001/tag/doc/versioning
Received on Thursday, 19 February 2009 12:58:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC