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

Henri Sivonen wrote:
>> My recollection of the TF's discussion around @version is that it was
>> a way to allow RDFa consumers to decide whether they wanted to parse a
>> page or not.
> 
> It seems that you failed to allow it.

Perhaps the current RDFa Syntax spec isn't clear enough on this matter.
We could add something as an Erratum. Could you please state some spec
text that would "allow it"?

>> But since we also didn't want to limit the use of RDFa to only those
>> publishers who had complete control over their pages, we didn't make
>> @version mandatory; RDFa as it stands can be placed in a blog post,
>> for example, without needing to change the blog sites templates.
>>
>> This combination of factors is why you're not seeing @version used
>> much in the wild.

Maybe... another reason might be that the following strings,

<html version="-//W3O//DTD W3 HTML 3.0//EN">
<html version="-//W3C//DTD HTML 3.2 Final//EN">
<html version="-//W3C//DTD HTML 4.01//EN">
<html version="-//W3C//DTD HTML 4.01 Frameset//EN">

are much more difficult to remember than:

<html version="HTML+RDFa 1.0">
<html version="5.0">

>> But you are right that from a *versioning* perspective, we don't need
>> to indicate a version until there is some different processing to do
>> -- such as a difference between a version 1.1 and 1.0.
> 
> But if you do need a version indicator for 1.1, wouldn't the problem of
> not completely controlling the page arise again? How is a version
> indicator for 1.1 supposed to work in Planet syndication?

You wouldn't /need/ a version indicator for 1.1. @version isn't a
MUST... it is a SHOULD. If the @version indicator wasn't specified on
the page, but the User Agent still decided to extract RDFa from the
page, then the latest RDFa processor rules known to the User Agent
should be used. So, if RDFa 1.1 were the latest version... the RDFa 1.1
rules would be used to extract the data from the page.

This same sort of behavior is occurring in the current HTML5 spec, so
this isn't a new concept we're talking about.

The difference is that authors aren't given the option to specify a
version that is meaningful in HTML5... as most every HTML-family
document (whether it is HTML 3.0, 3.2, 4.02, XHTML 1.0 or XHTML 1.1) now
becomes an (X)HTML5 document by default... with @profile being obsolete
even though it was perfectly valid when the author created the document.

> In any case, it's more relevant if any existing RDFa consumers (by
> default) modify their behavior when they get a version identifier from
> the future. Do they? (Philip's IRC remarks suggest they don't.)

What do you mean by this question? Are you saying, if an RDFa processor
today sees this:

<html version="XHTML+RDFa 1.1">

does it do anything?

>> * We'd like to ensure that web languages have the capability to make
>>  incompatible changes to match authoring behavior or fix past
>>  language design mistakes.
> 
> If you entertain the possibility of making incompatible changes to fix
> language design mistakes in the future, why are you unwilling to fix
> mistakes *now*? That is, if you are willing to make *some* incompatible
> changes, why isn't getting rid of prefix-based indirection in
> general--and using xmlns:foo in particular--one of the changes you'd be
> willing to make? (Note that you don't need xmlns:foo in order to Support
> Existing Content. It would be sufficient to hard-wire the currently
> common prefixes.)

I would hope the answer to this is evident, since there has been so much
discussion around it, but if it isn't, let me state it clearly:

The majority of the RDFa Community believes that removing prefix-based
indirection would be a huge mistake. The Web already has a way to refer
to resources - the URI, and we should re-use that. Using full URIs for
semantics in a page places an undue authoring burden on authors, thus
the need for a short-form URI. We are attempting to make this easier by
enabling keywords instead of prefix-based indirection, so:

<span property="title">The Lord of the Flies</span>

instead of

<span property="dc:title">The Lord of the Flies</span>

but I expect that RDFa will always have prefix-based indirection. I know
you (and a handful of others) personally think it was a language design
mistake, but the majority of the RDFa Community doesn't see it as such.

This is the reason we are unwilling to change that feature: It wasn't a
mistake.

That being said, with @version with /could/ change that feature in the
future without creating a backwards compatibility nightmare... without
@version, we will never be able to change that feature.

Henri Sivonen wrote:
> On Sep 29, 2009, at 15:43, Toby Inkster wrote:
>> But there's also nothing in the syntax document that requires it to
>> *start* processing. So an RDFa processor can simply opt to not begin
>> processing, depending on whatever factors it wants.
>
> It seems like a spec bug if main() { exit 0; } is a conforming RDFa
> processor.

Yes, quite clearly that would be a spec bug. However, I don't believe
that is what Toby was driving at...

I believe that Toby meant to say "So, a ***User Agent*** can simply opt
to not begin processing, depending on whatever factors it wants."

/Something/ has to trigger the start of RDFa processing. Typically, that
/something/ is the User Agent (or Application).

-- manu

-- 
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:03:06 UTC