Re: "index" link relation

On 2011-06-23 21:03, Tantek Çelik wrote:
> On Thu, Jun 23, 2011 at 08:20, Julian Reschke<julian.reschke@gmx.de>  wrote:
>> <http://microformats.org/wiki/existing-rel-values>  says:
>>
>> "Refers to a document providing an index for the current document.      was
>> in HTML4    explicitly dropped from HTML5"
>>
>> and has it under "dropped".
>>
>> That's very misleading; it was dropped from the spec, but the WG decision
>> explicitly mentions that not including it in the spec doesn't preclude it
>> being in the registry (and observes that it was in the registry what was the
>> registry-du-jour back then).
>
> Julian,
>
> Could you provide the URL (even if it is obvious) and a specific quote
> from the WG decisions that you are using to substantiate your
> conclusion that "not including it in the spec doesn't preclude it
> being in the registry (and observes that it was in the registry what
> was the registry-du-jour back then)" ?

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

"...It was pointed out in survey comments that these relations are 
already registered in the IANA link relation registry. Presumably, these 
relations could also be entered in whatever other registry or registries 
HTML5 adopts for this purpose. In support of this proposal, and against 
the proposals to retain or alter these relations, a number of arguments 
were presented."

(I actually supported the "winning" proposal under the assumption that 
it's better to have the proper values in the registry as opposed to 
broken values in the spec).

> I'd just like to be sure to cite some specific text so that we can
> minimize further thrash (excepting of course if new information or
> additional WG decisions change the outcome)
>
>
>> I believe this needs to go back to "proposed", and eventually need to be
>> registered.
>
> 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)
>
> Then absent any other information or explanation, it is presumed that
> the group/editors working on that specification decided to explicitly
> drop it (either in development, or in the updated version) and thus it
> should be obsoleted (not re-registered).

I think this rule of thumb makes sense in many cases, but this may be an 
exception.

> Basically, the only hard data in this case is previous existence and
> current non-existence of the value in the development/evolution of a
> specification.
>
> If there is more data, e.g. a link to an email of discussion of the
> spec development that explains *why* the rel value was dropped, and it
> explicitly states, e.g. it was without prejudice, or merely
> post-poned, or perhaps expected to be spun-out into its spec (or some
> other explicit positive reason), then it makes to link/cite that
> explicit text as part of a proposal.
>
> I've updated the wiki page accordingly with these additional details
> in the hopes that that helps provide a guide for folks to proceed
> rationally/scientifically in these cases.
>
> http://microformats.org/wiki/existing-rel-values#dropped
>
> If you have suggestions for improvement, or bug fixes to the above,
> please feel free to edit the wiki accordingly.
>
> Thanks,
>
> Tantek

Best regards, Julian

Received on Thursday, 23 June 2011 19:12:04 UTC