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

On Sun, Oct 11, 2009 at 10:31 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 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.

Ok, in an effort to not end up in a rat-hole discussion about the
meta-issue of what "backwards compatibility" means, let me get try to
refocus on the technical issue which I think we're ultimately
debating.

HTML5 does not have an attribute that says "if the attribute has value
X process the document according to HTML5 rules, if the attribute has
value Y process according to HTML4 rules". Instead it intends all
documents to be processed according to HTML5 rules. It's further
designed with the goal that future versions of HTML follow this
strategy. I.e. the goal is for HTML6 to define processing of all HTML
documents, without a switch indicating if documents should use HTML6
processing or HTML5 processing.

>> 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.

I would strongly recommend not to use the name "version" for any
specification that extends HTML, such as the HTML+RDFa specification.
The reason is that I think people will get confused and think it's a
version indicator for HTML, which I assume it's not meant to be,
right?

> 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)?

I would recommend against making such a change. There's *a lot* of
things I would like to change in HTML5 that would make it backwards
incompatible (for any definition of that term). However I think
backwards compatibility is more important than making those changes,
thus I have not recommended them.

Now, if you decide to make this change anyway, I would recommend
adding an attribute called something like rdfa-version. If the
attribute is missing, the document must be processed according to RDFa
1.0 rules. If the attribute is present and has the value "1.1"
(literal string comparison), then the document is processed according
to RDFa 1.1 rules. For any other value of the attribute, I'd say that
a consumer must not do any processing.

So a document starting with

<!DOCTYPE html>
<html rdfa-version="1.1">

use RDFa 1.1 processing.

/ Jonas

Received on Monday, 12 October 2009 06:40:16 UTC