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

Henri Sivonen On 09-11-11 09.23:

> On Nov 11, 2009, at 07:55, Manu Sporny wrote:
>>>> - Defining the new replacement mechanism for @profile as  
>>>> rel="profile"
>>> What problem does this solve?

    [...]

>> Are there instances where it is not a flaw? For example, when  
>> processing a page according to Microformats, GRDDL, RDFa
>> or DC-HTML rules?
> 
> As I understand it, processing the page as a whole according to RDFa  
> or Microformat rules isn't a flaw because there aren't competing  
> extensions using the same syntax as RDFa and Microformats. (Note that  
> the data expressed as RDFa or Microformats doesn't necessarily apply  
> to the whole page even though RDFa or Microformat processing is run  
> over the whole page.)
> 
> If the idea is that @profile should enable other extensions to use the  
> same syntax as RDFa or Microformats but with incompatible semantics,  
> then it would be a flaw to apply the same rules to the whole page, yes.

You jumped over DC-HTML.

Since it was present in the WHATWG developed spec, we discussed 
predefined class names early on in this WG. Rel values are like 
class names: Anyone could add their own values. This means that 
e.g. HTML5 could specify a rel name that is already occupied by 
someone's use - just as the earlier predefined class names could 
be occupied with undefined author semantics. To maintain semantics 
already specified - realizing that the HTMLwg has the power to 
overwrite any "private" semantics, one could thus point to a 
profile URI to avoid the overwriting that this WG has the power to 
make.

Though profile of course isn't only for (preventing) writing over 
semantics, but also for pointing to the semantics of "new" values.

> No, I wasn't making either assumption. I was pointing out that one can  
> adopt any of the following 3 positions and come to the conclusion that  
> there shouldn't be a rel=profile as drafted:
> 
>   1) Position: @profile a flawed concept. Conclusion: rel=profile is  
> conceptually the same, hence flawed, too.
>   2) Position: Applying @profile to the entire page is flawed.  
> Conclusion: <link rel=profile> is flawed, too.
>   3) Position: @profile is needed for compatibility with existing  
> specs that use @profile. Conclusion: <link rel=profile> is something  
> else, so it doesn't satisfy existing specs (without changing the  
> existing specs, which would make the specs new specs rather than  
> existing specs).
> 
> My point is that even with some freedom with choosing the premises,  
> the conclusion is that rel=profile as drafted doesn't help.

Would you be more comfortable with HTML5-EPB if it only specified 
@profile? Would you support a Change Proposal to HTML5 to get 
@profile back?

>> 2. There are a number of communities that have taken issue with  
>> @profile
>> being made obsolete, not because they have nothing better to do, but
>> because it affects them and has repercussions on their work. If HTML5
>> got rid of @profile and nobody complained, that would help to prove  
>> that
>> it is a useless feature - however, that has not happened.
> 
> So why are you introducing rel=profile and still obsoleting @profile  
> instead of writing a Change Proposal to introduce @profile as non- 
> obsolete?

Why don't you ask why Ian expressed that GRDDL etc should use 
rel="profile" instead of @profile? Therein lays the reasons for 
why HTML-EPB specifies rel="profile", AFAIU. I would be very 
interested in knowing Ian's justification. May be he simply wants 
to align the extension points - a draconian "purity" standpoint. 
Or may be he really thinks there is a feature difference. Or may 
be something else.
-- 
leif halvard silli

Received on Thursday, 12 November 2009 20:04:17 UTC