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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 12 Oct 2009 03:29:32 -0700
Cc: Henri Sivonen <hsivonen@iki.fi>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
Message-id: <04B50DF5-718D-478C-A061-4AADC0BB6D1C@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Oct 12, 2009, at 3:17 AM, Julian Reschke wrote:

> Maciej Stachowiak wrote:
>> ...
>>> We're back at the Distributed Extensibility discussion.
>> In any case, document-scope versioning is not a substitute for  
>> distributed extensibility. If two extensions to HTML use  
>> conflicting syntax, then a document-scope version (or feature use)  
>> declaration will not enable you to use both in the same document.  
>> This is true even if the extensions are different incompatible  
>> versions of the same extension.
>> ...
> 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.

> 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  

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.

Received on Monday, 12 October 2009 10:30:07 UTC

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