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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 11 Nov 2009 10:23:29 +0200
Cc: HTML WG <public-html@w3.org>
Message-Id: <CA89FE40-01ED-43C5-8CB0-46017CC18B4D@iki.fi>
To: Manu Sporny <msporny@digitalbazaar.com>
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?
>
> A number of other people have done a good job of outlining why the
> HTML5-EPB spec exists. Were you asking a more specific question, or do
> you have a more specific critique of the HTML5-EPB spec?

It seems to me that changing from @profile to <link rel=profile> is  
merely a syntactic transformation. I was asking what problem the  
syntactic transformation solves compared to using @profile (or having  
neither @profile nor rel=profile).

>> The reasons against @profile have been that the concept is flawed
>
> I agree that the execution was flawed, but the concept that @profile  
> was
> attempting to achieve isn't so flawed that it is useless. We should be
> asking another question: "Is @profile useful?"

 From what I've seen so far, it seems to me that it's not useful.

>> that even if the concept weren't flawed, having to make profiles  
>> apply
>> to the whole page is a flaw.
>
> You seem to be implying that applying profiles to a whole page is a  
> flaw
> most of the time. What evidence do you have that applying a set of
> processing rules to a whole page is a flaw (most of the time)?

It's a flaw on pages that aggregate content from multiple sources  
(either because or a server-side process pulls in content from  
multiple HTML documents or because a person copies and pastes from  
multiple documents into one).

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

> I don't follow the statements you've made because it sounds like  
> you're
> making these assertions:
>
> 1. @profile is flawed in concept.
> 2. @profile is not flawed in concept, but applying profiles to the
>   entire page is flawed.

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.

> As someone in this thread has already alluded, we could scope
> rel="profile", but we can't actually have that discussion until we
> understand that having a mechanism for specifying extended processing
> behavior is a worthwhile endeavor... flaws and all.

I agree that a scoping mechanism shouldn't be defined if it's  
concluded that there shouldn't be a mechanism at all.

> 1. For spec authors that would like to define extended processing
> behavior, there is currently no mechanism to do so provided in HTML5.

What's the point of introducing rel=profile instead of reusing  
@profile from HTML 4.01?

> 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?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 11 November 2009 08:24:14 UTC

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