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

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