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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 29 Sep 2009 10:37:07 +0300
Cc: Toby Inkster <tai@g5n.co.uk>, Philip Taylor <pjt47@cam.ac.uk>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
Message-Id: <857506F9-B8CE-4B39-975D-E1006BD196C3@iki.fi>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
On Sep 29, 2009, at 04:47, Mark Birbeck 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. A quick search through http://www.w3.org/TR/rdfa-syntax/ 
  for the string "version" suggests that http://www.w3.org/TR/rdfa-syntax/ 
  doesn't define any processing for @version. Therefore, there's  
nothing in the RDFa in XHTML spec that allows an RDFa processor to  
halt processing depending on @version and fail to extract the triples  
encoded in the document.

> It came about because some people were concerned that asking consumers
> to parse every document in order to see if there was any RDFa present
> was onerous. By providing @version, those consumers could choose to
> only process documents that explicitly flagged up that RDFa was
> present. Since these would probably be documents that the consumer had
> themselves generated, then it wouldn't make any difference to anyone
> else.

If it's only for self-consuming, it seems unnecessary to make the  
trigger part of the interoperable language. The class attribute  
already exists for channeling data for self-consumption use cases.

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

> However, at the moment, the problem with removing @version is that it
> has been defined as a 'trigger' to indicate the presence of RDFa, so
> that part needs to be taken into account.


As far as I can tell, it hasn't been *defined* to trigger anything.  
Could you please point me to the definition?

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

On Sep 29, 2009, at 01:03, Manu Sporny wrote:

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

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Tuesday, 29 September 2009 07:37:50 UTC

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