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

Smylers wrote:
>> 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:
> 
> Yes, but that doesn't affect backwards compatibility; it merely tells
> authors not to use these features.

Based on the responses to the e-mails I sent yesterday, it seems as if
we're using slightly different definitions of "backwards compatibility".
While I'm sure we're all being internally consistent, I think we're
talking past each other.

The discussion so far has been helpful and I learned a few things in the
responses, so thanks to Smylers, Toby, Maciej, and Jonas for taking the
time to respond. Here's what I think went wrong with the discussion:

Jonas responded to this thread by stating:

"I would personally recommend that RDFa follow the strategy that HTML
uses"[1] ... "To never break backwards compatibility with existing
content."[2]

I then muddied the waters by using the <center> element in an attempt to
express my assertion: That HTML-family languages have broken backwards
compatibility in the past. <center> was a bad choice for an example and
sent the discussion down a path that now has us talking past each other,
sorry about that. :)

Even worse, my selection of the @version attribute to address this
Extended Processing Behavior issue has re-raised the "Versioning of
HTML" debate... which I was attempting desperately to avoid. That's why
I presented @feature as an option, instead of @version... but too
little, too late.

Jonas then went on to state:

"HTML5 doesn't actually change behavior of anything (other than when
previous versions of HTML doesn't match reality)."[3]

Which reads to me as: HTML5 doesn't actually change the behavior of the
HTML4 spec... except when it does.

So, we now have people stating that:

1. HTML5 doesn't change the behavior of anything in a
   backwards-incompatible way.
2. HTML5 doesn't change the behavior of anything, except for parts of
   the HTML4 specification that don't match widely-deployed
   implementations.
3. HTML5 allows backwards-incompatible changes to be applied to
   previously conforming documents.

I believe #1 is false, #2 is more accurate and #3 is even more accurate
than #2, based on the definition of "backwards compatibility" that I'm
familiar with when it comes to standards. Here's my definition of a
backwards incompatible change as it applies to this discussion:

"Any change in HTML5 that, given an HTML5-conformant User Agent, will
cause a previously conformant HTML4 document to no longer be a
conformant HTML5 document."

So, instead of using <center>, let's look at the use of @rev in an <A>
element:

<a rev="subsection" href="http://example.org">A subsection</a>

In HTML4, this is conforming. In HTML5, this is NOT conforming.

Now, if one were to have a large number of articles written in HTML4,
migrating those articles to HTML5 isn't as simple as removing the
DOCTYPE at the top of the document. One must go in and manually edit the
documents, replacing @rev with @rel, in order to be conformant. If you
have to manually edit an HTML4 document in order to make it a conformant
HTML5 document, I'd argue that you've made a backwards-incompatible change.

After all, if you hadn't made a backwards-incompatible change... there
would be nothing that you would have to change to make the document
conformant again.

However, even if those arguing that HTML5 doesn't "break backwards
compatibility with existing content" were to agree with me, it doesn't
really move the @version/@feature discussion forward... other than
identifying that we do, in fact, agree on the problem.

> Whether HTML has depended on the version attribute is a matter for
> browser developers, not spec writers.  Jonas is a Mozilla developer.  If
> he says that Mozilla doesn't look at version numbers in order to process
> 'HTML4 pages' differently from 'HTML3 pages' (etc) then he knows what
> he's talking about.

I didn't mean to imply that Jonas doesn't know how Firefox treats the
@version attribute. I'm sure he does and I'd, of course, defer any
Firefox question to him in this discussion. However, I don't know if
Jonas was around for the design of HTML 2.0 or HTML 3.2, or HTML 4.01...
but I do know that Dan Connolly was around during that time frame.

I was more concerned around the reason behind @version at that time and
how its use was envisioned by the early designers of HTML than how
Firefox uses @version.

Anyway... moving on...

>>  * HTML5 breaks backwards compatibility for several good reasons.
> 
> It doesn't.

Do you see how it does using the definition of "backwards compatibility"
that I use above? I see how it doesn't based on the definition that you
are using, but that's not the definition with which I am concerned.

>>  * There is currently no way for an author to specify that they would
>>    like their documents to be processed as HTML5 instead of HTML6.
> 
> That's true, but then HTML6 doesn't exist yet.  HTML6 _may_ be developed
> with the same goals as HTML5, and as such retain backwards compatibility
> such that processing an HTML5 document with an HTML6 user agent will
> yield exactly the same behaviour and output as doing so with an HTML5
> user agent.  In which case no version specifier is needed.
> 
> Or HTML6 may make so many incompatible changes, along XHTML2 lines, that
> it fails to gain significant market share on the web or in mainstream
> browsers, in which case no version specifier is needed.

If you were intending to enumerate all the possibilities, you missed one:

Or HTML6 may want to make several backwards-incompatible spec changes
based on authoring use in the field such that default parsing behavior
matches real-world usage, in which case a version specifier is needed to
ensure that previously conforming documents continue to be conforming
after the change.

> But retaining backwards compatibility with the
> current web will require that documents without that attibute (or
> whatever) be processed according to HTML5 rules.  So it'll be as easy to
> add the attribute then as now, meaning doing it now has no advantage for
> HTML6.

No, it won't be easy to add the attribute then because the problem will
be non-deterministic at that point.

How will you know if somebody omits the @version tag on an HTML6
document if you should parse as HTML5 or parse as HTML6? If we create a
rule now that says anything that doesn't have a @version attribute will
be parsed using the latest rules known to the User Agent, we're covered.

However, if we add @version in HTML6, with no way to differentiate an
HTML5 document from an HTML6 document... you won't be able to make the
backwards-incompatible change in HTML7 either because you won't know if
the author didn't place @version in their document because they were
using HTML5 in a conforming manner, or if they just wanted their
document to be parsed using the latest version of HTML - HTML7.

When you stop versioning something - you create a non-deterministic
problem that can only be solved by /requiring/ a version specifier at a
later date.

>>  * 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.
> 
> True.  But possibly the FeatureX 2.0 spec could define that, rather than
> there needing to be a general HTML mechanism for it.  Given how
> undesirable backwards incompatibility is, HTML5 should not be
> encouraging it or making it easy.

That's certainly one way to look at it - another is that we don't want
to create a situation where we have no choice but to continue to live
with the mistakes we will inevitably make in authoring the HTML5
specification.

> Jonas Sicking wrote:
> But ultimately, if RDF and/or RDFa wants to change in a backwards
> incompatible ways that is of course up to the developers of those
> specifications.

I wish it were that simple.

We have already specified @version for XHTML+RDFa 1.0 and that's a REC.
The re-definition of @version was also in the HTML+RDFa 1.0 spec, but
was moved into the HTML5-EPB spec since it solved a more general problem.

We could move @version back into the HTML+RDFa spec... which the RDFa
Task Force would approve of because it would ensure that both XHTML and
HTML are processed in the same way and it also allows us to provide
backwards/forwards compatibility.

Then, I'm certain, some in the HTML WG would take issue with the fact
that HTML+RDFa makes @version conformant on HTML5 documents that contain
RDFa.

So, I'm curious - Smylers, Maciej, Jonas - assuming that the RDFa
Community wants to change the default behavior for XMLLiteral processing
to match authoring usage behavior... how should we make that change in
RDFa 1.1 that ensures that the RDFa 1.0 documents continue to be
processed as RDFa 1.0, but documents not marked with a version
automatically use the latest processing rules (RDFa 1.1)?

-- manu

[1]http://lists.w3.org/Archives/Public/public-html/2009Sep/1175.html
[2]http://lists.w3.org/Archives/Public/public-html/2009Sep/1213.html
[3]http://lists.w3.org/Archives/Public/public-html/2009Oct/0278.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 Monday, 12 October 2009 05:31:59 UTC