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

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

The discussion around this is here: 
<http://www.ietf.org/mail-archive/web/link-relations/current/msg00035.html> 
(but please read the whole thread), and our issue tracker lists it here: 
<http://paramsr.us/tracker/issue14>.

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