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

On Oct 12, 2009, at 4:20 AM, Julian Reschke wrote:

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

Allowing @profile on any element would indeed provide an extension  
disambiguation mechanism that allows fairly general combination of  
extensions (though you still couldn't use conflicting extensions on  
the same element). Another possible solution is providing XML-like  
namespaces and requiring all distinct extensions to use different  
namespaces. Yet another possibility is to have a registry for  
extension names as you suggested below.

But if we have a registry for extension names, I would suggest using  
extension names as prefixes in the markup (if we were designing RDFa  
from scratch, then "rdfa-about" instead of "about"), instead of  
declaring them out of band. Versioning could be right in the markup -  
rdfa2-about for an incompatible version, say. We could grandfather in  
existing extensions like RDFa 1.0, but still recommend this approach  
for new extensions.

  - Maciej

>
>>> 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:30:01 UTC