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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 12 Oct 2009 13:20:48 +0200
Message-ID: <4AD31110.30308@gmx.de>
To: Maciej Stachowiak <mjs@apple.com>
CC: Henri Sivonen <hsivonen@iki.fi>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
Maciej Stachowiak wrote:
>> That's true no matter what versioning/feature declaration mechanisms 
>> exist.
> 
> It's somewhat less true for subtree-scoped feature/version declaration. 
> Arguably, subtree-scoped versioning could be considered a form of 
> distributed extensibility. Though at that point, you need a way to avoid 
> collisions in the extension names.

URIs as extension names provide that.

So should I make a proposal to allow @profile on any block-level 
argument (only semi-kidding).

>> But the existence of these mechanisms at least allows to use 
>> incompatible extensions in *different* documents.
> 
> Only if you have a way to guarantee uniqueness of the extension 
> identifier. If we can't trust extension designers to coordinate enough 
> to use non-conflicting syntax, then can we trust them enough to make 
> unique identifiers? If we can trust them enough to make unique 
> identifiers, then couldn't we just propose a prefix convention for 
> extension syntax that uses the unique identifiers? The proposed @version 
> assumes that every extension will have a globally unique identifier.

...thus would need a registry, it appears.

> Also: is it really acceptable to ignore the use case of combining 
> content from multiple sources in one document (feeds, mashups, 
> user-generated content, etc)? That's the consequence of only caring 
> about different extensions in different documents. It seems to me that a 
> versioning mechanism which fails for this use case is not a good design. 
> It's not like we are forced to do it that way by legacy - we're 
> designing brand new mechanisms. Nothing stops us from getting that use 
> case right.
> ...

I agree that it would be good to solve this use case as well.

BR, Julian
Received on Monday, 12 October 2009 11:21:23 UTC

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