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

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 
  for the string "version" suggests that 
  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

Received on Tuesday, 29 September 2009 07:37:50 UTC