Re: "index" link relation

On 06/28/2011 09:21 PM, Tantek Çelik wrote:
> On Tue, Jun 28, 2011 at 02:54, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> On 2011-06-23 23:15, Julian Reschke wrote:
>>>
>>> On 2011-06-23 23:03, Tantek Çelik wrote:
>>>>
>>>> On Thu, Jun 23, 2011 at 13:47, Leif Halvard Silli
>>>> <xn--mlform-iua@xn--mlform-iua.no>  wrote:
>>>>>
>>>>> Tantek Çelik, Thu, 23 Jun 2011 12:03:59 -0700:
>>>>>>
>>>>>> I personally am not opposed to 'index' in particular (I've used it in
>>>>>> the past).
>>>>>>
>>>>>> However, I strongly prefer that we follow at least some sort of
>>>>>> rational/scientific methodology in such iterations so as to provide
>>>>>> objective (repeatable) reasoning of our actions, decisions, changes.
>>>>>>
>>>>>> So far I've been using the data available to reason how to treat
>>>>>> existing or previous rel values.
>>>>>>
>>>>>> In short:
>>>>>> * if a rel value was in a draft and is missing (without explanation)
>>>>>> from the final spec, or
>>>>>> * if a rel value was in a previous version of and is missing (without
>>>>>> explanation) from an update to the specification (even a draft update)
>>>>>
>>>>> A repeatable, objective criteria: HTML5 doesn't per se decide what goes
>>>>> into the Microformat registry. Rather, it is the opposite way. The
>>>>> Microformats registry is supposed to be the one which forms the basis
>>>>> for whether a link relation may pass the door to the HTML5
>>>>> specification.
>>>>
>>>> cite/link to HTML5 spec text or WG decision text that supports this
>>>> "supposed to be" assertion?
>>>
>>> That's usually the point of a registry.
>>>
>>> As such, I disagree with what Leif said as well: "The Microformats
>>> registry is supposed to be the one which forms the basis for whether a
>>> link relation may pass the door to the HTML5 specification."
>>>
>>> No! Usually the point of a registry is to *decouple* the container
>>> format from the definitions of extensions. Once you have a working
>>> registry, you don't need to include values into the base spec, except
>>> for those which *need* to be defined there.
>>>
>>> For instance, HTTP does have a registry for status codes. We don't
>>> *need* to include them into the base spec, unless they are somehow
>>> "special".
>>>
>>>> ...
>>>
>>> Best regards, Julian
>>
>> Tantek, what's the next step now?
>
> I was unable to follow Leif's reasoning - especially as it didn't
> cite/quote anything from the spec or the decisions.
>
>
>> Should I go ahead and edit the Wiki page?
>
> My concern is this, given that "index" was in the core HTML4 spec, and
> now isn't in the core HTML5 spec, we must be diligent in explaining
> *why* it is ok that we still register it (e.g. with specific quote
> from the WG decision that explains that it's ok).
>
> If you can find such a quote (and not have to add sentences/paragraphs
> of explanation/theory, i.e. this email thread), then yes, go ahead and
> edit the wiki to register 'index' and add that specific cite/quote of
> the WG decision.
>
> Otherwise I think the issue needs to raised back to the chairs for
> clarification.  Given that it was an issue raised to and resolved by
> the chairs in the first place, it behooves us ask them if we're unable
> to provide a clear direct quote that substantiates re-adding 'index'.

Generally the chairs limit themselves to evaluating proposals that 
actually are brought forward.

Here is the decision:

http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html

Here is the proposal that was selected:

http://lists.w3.org/Archives/Public/public-html/2010Nov/0042.html

If it is helpful, here are the proposals that were not selected:

http://lists.w3.org/Archives/Public/public-html/2010Oct/0268.html
http://lists.w3.org/Archives/Public/public-html/2010Oct/0269.html

http://lists.w3.org/Archives/Public/public-html/2010Nov/0041.html

And here is the survey results:

http://www.w3.org/2002/09/wbs/40318/issue-118-objection-poll/results

> Thanks,
>
> Tantek

- Sam Ruby

Received on Wednesday, 29 June 2011 02:01:02 UTC