W3C home > Mailing lists > Public > public-html@w3.org > April 2011

ISSUE-27 survey feedback, was: Responses to objections to the Microformats rel registry CP

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 04 Apr 2011 22:44:53 +0200
Message-ID: <4D9A2DC5.8080203@gmx.de>
To: Edward O'Connor <eoconnor@apple.com>
CC: HTML WG <public-html@w3.org>
On 02.04.2011 03:34, Edward O'Connor wrote:
> ...
>> 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.
> ...

Because we haven't got a spec that the designated experts (including 
myself) consider stable enough; note that this affect both content and 

The discussion around this is here: 
(but please read the whole thread), and our issue tracker lists it here: 

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

...added on April 1, so there was no way to look at this in detail in 
time before the end of the poll.

This is "new" information; do we need to restart the poll and ask for 
updated CPs? (this *is* a serious question).

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

Again, this information is new as of last Friday. So it appears that the 
statement about opaqueness was dealt with just in time :-)

> 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

Again, new information.

Believe me, I'm +1 (yes, pun) on the Microformats community taking a 
broader view, but it didn't before.

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

I'm not convinced that people who are able to edit a Wiki are unable to 
send an email.

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

<http://paramsr.us/tracker/issue21>, <http://paramsr.us/tracker/issue5>.

No, that's not part of the IANA registry, but it *is* part of the 
workflow of the designated experts.

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

The issue tracker provides information about what registrations are 
pending (or have been rejected).

I totally agree that it would be good if that kind of tracking was 
actually done by IANA, though.

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

So, just to clarify: this shouldn't be an objection because it's at the 
very heart of what we're trying to decide.

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

Doesn't compute. The HTTP link response header field is per document, so 
is <link>. <a>/<area> are on components of the document. This is the 
important distinction here.

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

Yes, we should.

Maybe this deserves a separate discussion.


Best regards, Julian
Received on Monday, 4 April 2011 20:45:39 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:35 UTC