Re: ISSUE-55: Re-enable @profile in HTML5 (draft 1)

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