Responses to objections to the Microformats rel registry CP

Hi,

These are my responses to objections to the "Defer to the Microformats
community for cataloging HTML rel values" Change Proposal. I should note
that these are my individual responses as author of the Change Proposal.

Toby wrote, in [1]:

> However, the same survey also notes that the top 11 rel values,
> between them account for 90% of the use of the rel attribute on the
> web. Comparing just those first 11 values, you find it comes out as:
>
> 	Microformats wiki: 8; IANA registry: 7.
>
> That's a pretty small difference, and I doubt it's statistically
> significant.

If we only care about the top ten or so values, why have a registry at
all? We could just list those 11 in the HTML spec and be done with it.

> This comparison also doesn't reflect the fact that the IANA registry
> has only been open for a couple of months. The expert review process
> takes time, and given time the IANA registry is likely to catch up in
> reflecting reality, and perhaps overtake the microformats wiki.

As we have seen in the past couple of months since your email, the IANA
registry hasn't caught up to the existing-rel-values page of the
Microformats wiki. For instance, it still doesn't document rel=pingback.

> While the microformats wiki offers a form of provisional registration,
> what remains to be seen is whether it offers a route for provisionally
> registered values to be achieve full registration.

This question is answered in the Microformats wiki's rel registry FAQ:

http://microformats.org/wiki/rel-registry#How_do_provisional_values_achieve_full_registration

> "Discoverability"
>
> Google for "rel registry" and the IANA one comes up as number 4. No
> microformats.org page is on the first page of Google.

I believe you'll find this is no longer the case, as is documented in
the Microformats wiki's rel registry FAQ:

http://microformats.org/wiki/rel-registry#Is_the_microformats_rel_registry_discoverable

> "Responses to anticipated objections"
>
> The process of becoming a microformats admin is opaque and does not
> appear to follow democratic or indeed easily understood principles.

On the contrary, the process is farily straightforward, and is publicly
documented on the Microformats wiki, in the Admin FAQ:

                 http://microformats.org/wiki/admin-faq

Julian wrote, in [2]:

> It would be great if the Microformat community was also willing to be
> the registry for rel values, independently of where they occur in.

I'm not in a position to speak to what the Microformats community is or
isn't willing to do. That said, the Microformats wiki's
existing-rel-values page is format-agnostic, not HTML-specific:

http://microformats.org/wiki/rel-registry#Can_the_microformats_rel_registry_document_HTML_specific_details

>> Ease of registration of pre-existing values
>>
>> All things being equal, it should be as easy as possible for
>> interested parties to register already-deployed HTML rel values. Such
>> interested parties might not be the originators or publishers of such
>> HTML rel values.
>
> Yes.
>
>> The Microformats listing is maintained on a wiki page, and as such is
>> straightforward for anyone to update at any time[…]
>
> Yes. How is that relevant?

It's relevant because a wiki is pretty much the definition of "as easy
as possible."

>> Several widespread HTML rel values (tag, external, pingback, and
>> various XFN values come to mind) are absent from the IANA registry[…]
>
> "tag" and "external" have open bugs in the HTML WG, and thus their
> registration is pending until this WG has resolved these issues.

This demonstrates the need for a provisional registration mechanism.

> No, there is not because we believed that registration is simple enough
> so that separate categories aren't needed.

I think it's safe to say that you were incorrect to believe that at that
time.

>> While atom:link superficially resembles HTML's link element, Atom rel
>> values are (currently) distinct from HTML rel values. This WG has
>> made no decision on whether or not unification of Atom and HTML rel
>> values is a goal we should pursue.
>
> I think that's a decision we're trying to make here.

Indeed.

> As a matter of fact, I'd expect any relation that works in link/@rel
> to be usable as is in an HTTP Link header.

We already have rel values that work in <link> but not in <a>/<area>.
Given that, it's not unreasonable to expect there to be future rel
values that differ between formats, and even within the same format.

>> If we adopt the IANA registry, we prevent future HTML rel value
>> minters from minting "modifier" rel values which augment other
>> values. While this CP takes no position on whether or not such
>> "modifier" rel values are sound design, they do have precedent in the
>> Web platform (stylesheet alternate, shortcut icon) so it's reasonable
>> to suppose such things may be minted in the future.
>
> Yes. That's a feature.

It's a bug. HTML has created such rel values in the past; we shouldn't
restrict our ability to mint them in the future.

Julian wrote, in response to the ISSUE-27 straw poll[3]:

> Also, I recall people asked for machine-processable content of the
> registry (for validators). How does the Microformats Wiki address
> this?

http://microformats.org/wiki/rel-registry#Is_there_a_machine_processable_version_of_the_microformats_rel_registry

> As far as I can tell, that mail didn't get any feedback from Edward.

Replies above.

Roy wrote, in response to the ISSUE-27 straw poll[3]:

> All prior HTML practice and Web relations are either missing or
> incorrectly defined in that page.

It's a wiki; if you know of any specific inaccuracies or omissions,
please correct or add them.

> that page incorrectly treats XFN as authoritative

XFN are some of the most widely published and well established rel
values on the Web; if a rel value registry failed to list them, that
registry would be less useful to Web authors.

Ted

[1]: http://lists.w3.org/Archives/Public/public-html/2010Dec/0089.html
[2]: http://lists.w3.org/Archives/Public/public-html/2010Dec/0112.html
[3]: http://www.w3.org/2002/09/wbs/40318/issue-27-objection-poll/results

Received on Saturday, 2 April 2011 01:35:02 UTC