W3C home > Mailing lists > Public > public-html@w3.org > October 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 12 Oct 2009 01:13:13 -0700
Message-ID: <63df84f0910120113y46353eb0uee96539b7a88e74a@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
On Mon, Oct 12, 2009 at 1:03 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Oct 11, 2009, at 11:39 PM, Jonas Sicking wrote:
>
>>
>>> 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.
>
> That would be my general recommendation too. Anything without a version
> marker has to be assumed to be RDFa 1.0, since all RDFa content today is 1.0
> and the vast majority does not contain any reliable version indicator. But
> there are many alternatives to rdfa-version, such as use of profile, or
> simply changing the name of the attribute whose processing would change
> under 1.1, thus allowing documents to have correct RDFa 1.0 and 1.1 at the
> same time. If there is a separate version indicator, it should be allowed on
> any element so that for use cases like syndication each fragment can
> indicate the version.

I was thinking about the per-subtree-version-indicator when I wrote my
post. While I agree that it makes it easier for content producers that
produce a snippet of markup, it adds significant complexity to the
language. Just look at the amount of complexity xml:base or xmlns
produce.

Not sure I have a firm recommendation on the subject, just wanted to
highlight some (what I consider) significant downsides with the
approach.

/ Jonas
Received on Monday, 12 October 2009 08:14:05 UTC

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