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
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 12 October 2009 07:23:10 UTC

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