- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 10 Oct 2009 15:43:17 -0400
- To: HTMLWG WG <public-html@w3.org>
Jonas Sicking wrote: > On Tue, Sep 29, 2009 at 12:33 AM, Toby Inkster <tai@g5n.co.uk> wrote: >> On Mon, 2009-09-28 at 17:32 -0700, Jonas Sicking wrote: >>> I would personally recommend that RDFa follow the strategy that HTML >>> uses >> To only provide version identifiers for the first four versions? > > To never break backwards compatibility with existing content. The > "version identifiers" in earlier versions of HTML were never, to my > knowledge, used as a way to break compatibility with older versions of > the specification. I think you're missing Toby's point. Let me attempt to elaborate in order to shed some light on the issue. At present, your statement that HTML5 will "never break backwards compatibility with existing content" is not true. HTML5 breaks backward compatibility in many (good) ways... it obsoletes a number of HTML features: http://dev.w3.org/html5/spec/Overview.html#non-conforming-features Now, I don't know the intent of the Non-conforming features section, but after reading Section 12.2, if I were to write a User Agent - I expect that I wouldn't have to support any of those features. For example, if my web browser saw <center>, it would ignore it completely and be fully conformant with the HTML5 specification, IIRC. Since most HTML4 documents are now magically HTML5 documents, how does this not break backward compatibility in this particular scenario? In an HTML5 conformant browser, suddenly, text will no longer be required to be centered. When you say that "we should strive to not break backward compatibility", you are right. It is a noble goal. However, after years of language design and re-design, we will eventually break backward compatibility for a number of good reasons. HTML has done it numerous times and is doing it right now. So, the question is: How do we allow for deep changes to a language in the future, but ensure backwards compatibility for those that want to ensure their document is processed in the same way in the future? That is the question that the HTML5-EPB[1] spec attempts to answer. Somebody that is far more knowledgeable and astute than I am (I'm looking at you Dan Connolly) about the history of HTML and what compatibility was or was not broken from version to version will have to enlighten us. Specifically, on whether your assertion that pre-HTML5 hasn't broken backwards compatibility and depended on the @version attribute to differentiate between different versions of the spec, is true. I think we've done that in the jump from HTML4 to HTML5 - and we've done it in such a way that is largely undetectable to User Agents reading conforming HTML5 documents. So, * HTML5 breaks backwards compatibility for several good reasons. * There is currently no way for an author to specify that they would like their documents to be processed as HTML5 instead of HTML6. * There is currently no way for an author to specify that their document uses a number of extended processing behaviors built on top of HTML5. * There is currently no way for an author to specify that their document should be processed via extended processing behavior using FeatureX version 1.0 instead of FeatureX version 2.0. As I've stated previously, this is a technical issue and is directly relevant to XMLLiteral generation in RDFa 1.0 vs. RDFa 1.1. -- manu [1]http://html5.digitalbazaar.com/specs/html5-epb.html -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: The Pirate Bay and Building an Equitable Culture http://blog.digitalbazaar.com/2009/08/30/equitable-culture/
Received on Saturday, 10 October 2009 19:43:48 UTC