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

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