W3C home > Mailing lists > Public > www-archive@w3.org > April 2011

[wbs] response to 'ISSUE-27: @rel value ownership, registry consideration - Straw Poll for Objections'

From: WBS Mailer on behalf of tantek@cs.stanford.edu <webmaster@w3.org>
Date: Sat, 02 Apr 2011 01:21:02 +0000
To: tantek@cs.stanford.edu,www-archive@w3.org
Message-Id: <wbs-dd8ecf0b82bcade498603e4458716e85@cgi.w3.org>

The following answers have been successfully submitted to 'ISSUE-27: @rel
value ownership, registry consideration - Straw Poll for Objections' (HTML
Working Group) for Tantek Çelik.



---------------------------------
Objections to the Change Proposal to replace the Wiki link relation
registry with that defined in RFC 5988
----
We have a Change Proposal to replace the Wiki link relation registry with
that defined in RFC 5988. If you have strong objections to adopting this
Change Proposal, please state your objections below.  Keep in mind, you
must actually state an objection, not merely cite someone else. If you feel
that your objection has already been adequately addressed by someone else,
then it is not necessary to repeat it.
Objections: 
1. TLDR. Understanding/use/participation in the registry defined in RFC
5988 is far too difficult, and frankly, inaccessible due to the length and
cryptic/technical/jargon wording of http://tools.ietf.org/html/rfc5988

2. Empty promises / hidden work. The Change Proposal uses the phrase
"Nothing prevents us ..." and these show holes. Every such encouragement to
do something indicates known shortcomings in use of IANA/RFC5988 and some
amount of hidden work in order to make this a workable solution.

3. Misleading / out of touch. The proposal says "requirements for
registration are low" - this is misleading or fails to understand the
audience for adding rel values. Understanding/following RFC5988 is *not* a
low requirement, e.g. see 1. above, rather it is quite onerous and
demanding of a high level of technical comprehension and patience, making
it inaccessible to perhaps most web authors, many of whom have proposed rel
value in microformats.

4. Too many steps. The HTML5 editor had difficulty with the number of
steps required with RFC5988 rel registrations. There is no documented short
list of the steps to take, web form to use, etc.

5. No provisional registration. There is no mechanism for simple
brainstorm proposal documentation of in-development rel values, e.g. for
the purpose of easier discovery for collaborative development and collision
avoidance.

6. Apparent dependency on email. RFC5988 says "sent to the
link-relations@ietf.org mailing list" - email is a primitive tool for this,
and given that there are known solutions using wikis, web forms etc. those
should be preferred.

7. Designated Expert bottleneck. RFC5988 says "the Designated Expert(s)
will either approve or deny the registration request" whereas it is much
more desirable to simply have any/all attempted registrations be public in
some sort of provisional or brainstorm status by default, and only then
optionally acted upon by experts.

8. Failure to cite original/active specs. RFC5988 "Initial Registry
Contents" lists for example "license" which links to RFC4946 which itself
fails to cite the *actual* rel-license specification from which it took a
snapshot: http://microformats.org/wiki/rel-license.

9. Failure to perform even trivial research/linking. The RFC5988 entry for
"payment" says "Notes: this relation type registration did not indicate a
reference." Googling "rel payment" returns the microformats draft for
rel-payment: http://microformats.org/wiki/rel-payment which should have
been referenced by RFC5988. This real world example is indicative of a
process/thoroughness breakdown.

10. Unfriendly to / misleading regarding microformats. The proposal says
"a stable document (e.g., a W3C Note, IETF RFC, publication on
microformats.org)." and yet NONE of the entries on
http://www.iana.org/assignments/link-relations/ reference microformats.org
specs/drafts for those rel values which were/are developed and maintained
on microformats.org like: license, nofollow, payment, tag.




---------------------------------
Objections to the Change Proposal to have a registry be hosted by the W3C 
----
We have a Change Proposal to have the registry be hosted by the W3C. If
you have strong objections to adopting this Change Proposal, please state
your objections below.  Keep in mind, you must actually state an objection,
not merely cite someone else. If you feel that your objection has already
been adequately addressed by someone else, then it is not necessary to
repeat it.
Objections: 
1. No experience. There is no experience with W3C hosting a rel values
registry other than the HTML specifications. With that experience alone the
update cycle is too slow (with perhaps the exception of the HTML5 editor's
draft which is updated quite frequently, however has a single-editor
bottleneck).

2. Anticipated higher barrier to entry. Speaking in theory (since there is
no such registry yet) and based on experience in other W3C efforts, the
process that is expected to be required will likely be more work than
simply editing a wiki page.




---------------------------------
Objections to the Change Proposal to use the microformats Wiki page for
the registry
----
We have a Change Proposal to use the microformats Wiki page for the
registry. If you have strong objections to adopting this Change Proposal,
please state your objections below.  Keep in mind, you must actually state
an objection, not merely cite someone else. If you feel that your objection
has already been adequately addressed by someone else, then it is not
necessary to repeat it.
Objections: 
Disclosure: I am a founder and admin of microformats.org.

I believe the following addresses the issues raised by other survey
respondents to date with respect to using the microformats wiki as a rel
registry:

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

If not, I hope that the documentation therein and the good faith attempts
at doing so, both publicly, and in a manner which is easily discoverable
(e.g. via search engines) demonstrates that any issues raised even on an
ongoing basis will be resolved.

Thanks for your consideration.


These answers were last modified on 2 April 2011 at 01:18:54 U.T.C.
by Tantek Çelik

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/40318/issue-27-objection-poll/ until
2011-04-01.

 Regards,

 The Automatic WBS Mailer
Received on Saturday, 2 April 2011 01:21:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:35 GMT