- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 11 Nov 2009 00:55:42 -0500
- To: HTML WG <public-html@w3.org>
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