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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 12 Oct 2009 10:22:21 +0300
Cc: HTMLWG WG <public-html@w3.org>
Message-Id: <849643B3-6074-4B3E-8648-BB7205BF9E1E@iki.fi>
To: Manu Sporny <msporny@digitalbazaar.com>
On Oct 10, 2009, at 22:02, Manu Sporny wrote:

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

I opt not to use my time for drafting proper text for doing something  
that I think is in itself improper. That is, I think you shouldn't  
have @version at all for RDFa and I especially think (X)HTML (or SVG  
or MathML) should not have @version at all.

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

That's an interesting way of doing versioning especially when the  
current practice (as analyzed by Philip) is that RDFa-in-"XHTML"- 
served-as-text/html authors don't include a version attribute at all.

When RDFa 1.1 is published, how do you expect legacy content to gain a  
version 1.0 version identifier all of a sudden? If you don't expect it  
to gain a version 1.0 identifier, how is the situation different from  
not having the version attribute at all?

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

More to the point, the old documents are processed according to the  
HTML5 processing rules. That's a feature, not a bug. (It's not  
particularly useful to discuss if the abstract essence of the existing  
documents changes from valid HTML.old to invalid HTML5. New documents  
should be written to be valid HTML5, though.)

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

I mean: If an RDFa 1.0 processor sees version="XHTML+RDFa 1.1", does  
it do anything differently compared to not seeing a version attribute  
at all.

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

How? (Given the current reality of the absence of @version in existing  
content and your statement that future RDFa processors would default  
to the latest version.)

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

So, in black-box terms, is |main() { exit 0; }|, in your opinion, a  
conforming User Agent that embeds an RDFa processor? This UA just  
happens never to opt to trigger the start of RDFa processing.

Henri Sivonen
Received on Monday, 12 October 2009 07:23:10 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:52 UTC