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

Henri Sivonen wrote:
> On Nov 4, 2009, at 06:18, Manu Sporny wrote:
> 
>> http://html5.digitalbazaar.com/specs/html5-epb.html
>>
>> Changes, as outlined last week[3], include:
>>
>> - Removing @version completely
> 
> Thank you. You didn't remove it from the informative text, tough. Now
> the informative text looks out of place. I think it would make sense to
> remove the informative text that talk about @version.

I agree that the text on @version looks a bit out of place right now.
I'm concerned about removing it entirely because the document is
discussing "Extended Processing Behavior", which has traditionally been
triggered by @profile (GRDDL, DC-HTML, RDFa 1.0, etc.) and @version
(RDFa 1.0).

One could argue that we don't talk about rel="stylesheet" or the
<script> tag, which are types of "Extended Processing Behavior", and
that we should add those to be inclusive. A counter to that point could
be that neither rel="stylesheet" or <script> is about extracting data
from the HTML markup, whereas @profile and @version do affect data
extraction from the HTML markup.

That being said, I can reword it to make that point more clear - or
remove it if enough people think that explaining that in the background
and introduction section is unnecessary.

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

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

More below...

> 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)? Are there
instances where it is not a flaw? For example, when processing a page
according to Microformats, GRDDL, RDFa or DC-HTML rules?

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.

Let's assume that #1 is correct and that @profile is "flawed". Per the
definition of "flaw": 1) an imperfection in an object or machine, or 2)
an imperfection in a plan or theory or legal document that causes it to
fail or that reduces its effectiveness.

So we are asserting that @profile is imperfect, but that doesn't help us
 decide on whether or not it isn't useful. Plenty of things that are
imperfect are useful - just because an apple contains a blemish doesn't
mean that we throw the entire thing away. So, if we are going to get rid
of @profile, we're going to have to do better than say that it is
"flawed". We have to prove that it is not useful.

Now let's assume that #2 is correct, that @profile isn't flawed, but
applying a profile to the entire page is flawed. This one is a bit
easier to analyze as we have many processors that apply the same rules
to the entire page - CSS, RDFa, Microformats, HTML parsing, and
Microdata apply the same processing rules to the entire page. So, there
are many instances where applying processing rules to the entire page is
beneficial. I'm guessing that you meant something else by that
statement, but I can't understand what it could be based on what you wrote.

> How does recasting @profile into a
> <link>-only rel value solve address either conceptual flaws or the
> limitations in being able to scope profiles to only a part of the HTML
> document?

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.

> The reasons in favor of @profile have been that GRDDL (etc.) uses it
> already. How does introducing a syntactic transformation that isn't
> recognized by pre-existing GRDDL (etc.) tools help GRDDL (etc.)?

If that is your complete understanding of the arguments for @profile,
then I think we've found the mis-communication. What you stated above is
but one issue surrounding @profile.

Here are the two primary issues that were created by making @profile
obsolete in HTML5:

1. For spec authors that would like to define extended processing
behavior, there is currently no mechanism to do so provided in HTML5.
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.
3. If we are to migrate to a less-flawed approach, there should be a
transition plan and clear guidance.

These three issues alone warrant an HTML5-EPB spec. These are problems
that we need to addressed in some way.

We should be talking about possible solutions to the problems listed
above, not arguing over whether the problem exists or not. Clearly, it
does - there have been many complaints, it has become an ISSUE and there
is a spec to address the issue. If the solution is flawed, we should
find a mechanism that is less flawed and transition toward that solution.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/

Received on Wednesday, 11 November 2009 05:56:13 UTC