W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: Versioning re-visited (was : mixed signals on "Writing HTML documents", tutorial, etc.)

From: Dimitri Glazkov <dimitri.glazkov@gmail.com>
Date: Fri, 22 Jun 2007 10:22:37 -0500
Message-ID: <fb15ac210706220822oc37d5fn366fc99a7bb035ed@mail.gmail.com>
To: "Ian Hickson" <ian@hixie.ch>, "Alexandre Alapetite" <alexandre@alapetite.net>, public-html@w3.org

It seems that those arguing for versioning could start with specific
examples where versioning resolves a conflict, perhaps in semantics of
elements or attributes, and not theoretic experiments.

I find myslef quite fond of the idea of _one_ HTML, with well-defined
fallback and error handling, backward and forward compatible and I
can't fathom the cruelty of changing the meaning of same markup from
version to version, thus necessitating the need for formal versioning.

But it does not mean that such idealistic notion, while quite
desirable, is possible in reality. That's why we need you, the
naysayers, to debunk with concrete examples. If I happened to miss
this information in the prolific flood of data that is public-html
mailing list, please direct me to the right postings.

:DG<

On 6/22/07, Ian Hickson <ian@hixie.ch> wrote:
>
> On Fri, 22 Jun 2007, Alexandre Alapetite wrote:
> >
> > Anyway, since we are there, I have problems with your argumentation
> > since you do not really explain why we should /not/ have versioning,
> > but instead you try to show that versioning is sometimes superfluous.
>
> I detailed the reasons for not having versioning in a previous mail, to
> which I linked:
>
>    http://lists.w3.org/Archives/Public/www-archive/2007Jun/0024.html
>
> ...which itself links to three more e-mails giving arguments against
> versioning. The purpose of my last e-mail was not to give arguments
> against versioning, since those have been discussed in detail already, but
> to show that the arguments _for_ versioning were weak or wrong.
>
>
> > > > * An explicit version helps a browser or any reader to know the
> > > > intention of the author.
> > >
> > > This only works if the author actually knows what his intent is. 50%
> > > of pages on the Web have no DOCTYPE [1]. So it's not clear to me that
> > > you can actually determine the intention of the author from the
> > > version.
> >
> > Your reasoning is strange to me: if the author of a Web page did not
> > chose to include an explicit version, then there is none... Furthermore,
> > from your own statistics, 50% of the Web pages /do/ have versioning. It
> > would also be interesting to know how this proportion evolves over time,
> > with the CMS, editors and Web masters becoming better. For all those
> > people who /chose/ to have explicit versioning, your argument does not
> > seem to be valid.
>
> More data would indeed be useful; however, my point was that authors
> rarely know what their intent is, and that versioning information in a
> document is therefore a poor guide as to their intent.
>
>
> > > Furthermore, if you keep your language backwards-compatible, the
> > > intent of the author is independent of which version was current when
> > > the document was written. So versioning isn't the only way to catch
> > > author intent.
> >
> > That is not a point against versioning. You just say that /maybe/
> > versioning is superfluous in some cases.
>
> Right. I'm pointing out that this argument for versioning is weak, as
> there are better ways to solve the purported problem.
>
>
> > > > * Versioning is needed to update the HTML recommendation without
> > > > breaking existing content.
> > >
> > > This is clearly untrue, since the version has never been used for this
> > > purpose despite HTML being on its 9th revision (HTML1, HTML+, HTML2,
> > > HTML3.2, HTML4, HTML4.01, XHTML1, XHTML 1.1, HTML5/XHTML5). (Some of
> > > those revisions did have version information -- though not all -- but
> > > in no case was the version identifier used to avoid breaking content.)
> >
> > There are differences between all those version, both in the syntax,
> > grammar and semantics.
>
> Indeed, but in none of the above cases has versioning been used to allow
> recommendations to be updated without breaking existing content. User
> agents have not looked at the versioning information to infer the version
> of the document and act appropriately at any point in HTML's deployment.
>
>
> > > > * It allows the automatic validation of the HTML documents against
> > > > the precise HTML version they are targeting.
> > >
> > > This is still possible without version information, you just need to
> > > tell the conformance checker what you intend to test against. CSS
> > > works like this, for instance.
> >
> > By definition, "automatic" means that there is no such a "you just need
> > to tell"... So the point for versioning is still valid. While it is true
> > that it is possible to pick up by hand the version to use (if the author
> > has a way to remember which version was used for one given document), it
> > is harder when you face thousands of documents from various generations.
>
> I agree that it is not possible to automatically select the version that
> was contemporary when the document was written. However, I contend that
> that is not a desirable feature, and may in fact be undesirable as it
> results in outdated conformance reports with false-negatives and false-
> positives. See the earlier cited e-mail.
>
>
> > > > * Allows "flavours" of HTML such as "XHTML Basic".
> > >
> > > Profiling the data-level language is harmful, but even if it wasn't,
> > > versioning isn't actually required to do it. CSS, for example, is not
> > > versioned but has been successfully profiled many more times than
> > > HTML.
> >
> > Well, I do not know if CSS is a good example, but I personally do miss a
> > version and profile, for instance to do automatic validation.
>
> My point here was related to the purported advantage of versioning. I'm
> merely pointing out that this purported advantage is not actually related
> to versioning and shouldn't be used to support explicit versioning.
> Versioning doesn't enable profiling. They are orthogonal.
>
>
> > > > * A validator may advise updating to a newer version if it can
> > > > automatically tell what version was used, and another tool may
> > > > provide some help in the conversion to the newer version.
> > >
> > > If you omit versioning information and ensure the language remains
> > > backwards compatible, there is actually no need to update anything.
> >
> > Here again, you say that /if/ we are lucky and things stay as you want
> > them to be, versioning may be superfluous. No point against it there.
>
> We're talking about versioning in HTML5. We have control over HTML5.
> Modulo the argument below (that adding versioning to a future version when
> HTML5 doesn't have it would be aesthetically displeasing), I don't see
> that not having versioning at this point would stop a future version from
> readding versioning and re-enabling these notifications if backwards
> compatibility was to be sacrificed at some future point.
>
>
> > > > * A special extra knowledge will be needed to know that <!DOCTYPE
> > > > html> means HTML 5 (or any later version until a version mechanism
> > > > is re-introduced).
> > >
> > > It doesn't mean "HTML5", it means "HTML".
> >
> > Well, this depends on the view point. Since HTML 4 is not valid HTML5,
> > you may have to tell the authors of all those HTML 4 pages that they are
> > not doing HTML pages after all.
>
> HTML4 is also HTML. I don't understand what you mean. My point was that
> the proposed HTML5 DOCTYPE, without versioning information, merely
> indicates that the document is an HTML document, not that it is an HTML5
> document (or any other version, for that matter).
>
>
> > > > * There will be no consistency with previous HTML versions if we use
> > > > <!DOCTYPE html> for HTML 5 and need to reintroduce the public
> > > > identifier in later versions.
> > >
> > > True. Of the ones you listed, this seems to be the only valid reason
> > > to have versioning.
> >
> > Good, at least we agree on one point.
>
> Indeed.
>
>
> > > So in conclusion, as I see it the arguments in favour of versioning
> > > boil down to aesthetics, and the arguments against include dire things
> > > like us losing competitiveness in the browser space. [2] [2]
> > > http://lists.w3.org/Archives/Public/www-archive/2007Jun/0024.html
> >
> > Actually, regarding "competitiveness in the browser space", I would like
> > to point you again to the arguments from the Internet Explorer team:
>
> Given that the danger of versioning resulting in anti-competitive
> behaviour was first brought up specifically because the IE team was
> suggesting implementing a versioning feature that would have long-term
> anti-competitive effects on the browser market, and that Microsoft is a
> convicted monopoly-abuser in several jurisdictions and therefore has a
> track record of taking advantage of features that can be leveraged against
> healthy competition, I am not sure that appealing to Microsoft's position
> is an effective counter-argument here.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>
Received on Friday, 22 June 2007 15:22:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC