W3C

Site Navigation

Nearby

Results of Questionnaire ISSUE-27: @rel value ownership, registry consideration - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-17 to 2011-04-01.

8 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to replace the Wiki link relation registry with that defined in RFC 5988
  2. Objections to the Change Proposal to have a registry be hosted by the W3C
  3. Objections to the Change Proposal to use the microformats Wiki page for the registry

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

Details

Responder Objections to the Change Proposal to replace the Wiki link relation registry with that defined in RFC 5988
Jonas Sicking IANA does not have a good track record of operating registries that affect formats higher up in the protocol stack. For example the HTTP header registry is notoriously out of date and so far IANA seems to have made no effort to fix this. Instead blame is being pushed around and no change occurs. For example, IANA appears to be completely unwilling to go out and look at what is out there and add it to the registry, and instead insist that other people add things to the appropriate registry, leading to absurd situations where headers are known by everyone except the actual registry.

To make this worse, despite claims to the contrary, IANAs registration process is so heavy weight that many people give up. See the experiences documented here for an example:
http://lists.w3.org/Archives/Public/public-html/2010Aug/0161.html

While IANA has claimed that changes can be made to improve the situation, so far it doesn't appear that these changes have been made giving me little reason to believe that they will in the future. And no reason to believe that they'll be made in a satisfactory way.

If IANA want to be responsible for running the rel registry I think they need to prove themselves first. Let them show that they are running a rel registry which is up to date. Either by asking people who register in whatever official registry we come up with to also register with IANA (that should give them incentive to keep the bar for registering low), or by manually adding the entries themselves. Something that they undoubtedly will need to do even if they were the official registry as no matter how low we make the bar, some people won't know or care enough to register.
Leif Halvard Silli
Ian Hickson The main issue with this change proposal is that it unifies relation types across multiple protocols and document formats. The rel="" attribute in HTML applies just to HTML; other formats, including metadata outside documents, have different needs and rel="" values should not therefore be forced to have a consistent meaning no matter where they show up.

(This does not preclude implementors who have link types that apply to multiple formats from applying them to multiple formats, so long as they follow the applicable rules for each of these formats.)
Julian Reschke
Roy Fielding
Danny Ayers Counter-points in response to the Objections to the Change Proposal.

There are known problems with the IANA registry in not reflecting current practice, but such problems can occur with any registry. Adding another registry to the ecosystem does not close the door to such problems, rather it adds another point of failure.

Yes, the use of RFC 5988 unifies relations defined by the Link: header, but its scope is limited to just that. Whether a format or protocol relies on this header for its definition is a separate matter. There is currently no evidence that divergent semantics of relations is desirable across formats and protocols (the interests of interoperability would suggest otherwise), but even were this the case, there is nothing to preclude the use of a different header for the purpose.

Generally I think the use of URIs for rel values should be encouraged over the use of a registry anyway to avoid centralised points of failure, or to put it another way, the registration should be distributed across the Web at large using the Web's naming scheme.
Tantek Çelik 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.
Theresa O'Connor If the barrier to rel value registration is too high, common rel values will fail to be registered. This has already happened with the RFC 5988 registry (rel=pingback, one of the top 25 most common rel values in use, is just one example of this). Should we adopt this registry, we would put Web authors wanting to use such rel values in the situation where they have to choose between using the rel value on the one hand and producing conformant HTML on the other.

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

Details

Responder Objections to the Change Proposal to have a registry be hosted by the W3C
Jonas Sicking
Leif Halvard Silli Registration difficulty: Since 'ratified' status of the XPointer-inspired registry depends on a W3C spec or Microformats approval, Ian's test registration attempt (which was of his private spec) would have resulted in a 'proposed' state registration for at least as long as the RFC5988-registry refused to take it in.

Reality reflection: Unlike the initial RFC5988-registry, this CP says that only relations with a W3C or Microformats specifications in their back, can get 'ratified' status. This is a higher bar than RFC5988 has (which only lists 'ratified' relations, though). It would also be a barrier to reflect 'reality' as it seems like link types from specs outside W3C/Microformats, can only reach 'proposed' status. Even the XPointer schem registry does not have a similar barrier - as there the specs for the schemes can be located everywhere.

A new registry: The net result could easily be that we get two registries - a RFC5988-registry and this registry. Were this registry often would be like a preparatory registry for RFC5988-regstriation. OTOH, we could also get a situation where not everything in RFC5988 would/could be 'ratified' in this registry because it does not appear in W3C or Microformats space.

Lack of testing: Unlike both Microformats and the RFC5988 registry, there is no testing and track record.

Proposed status: The 'proposed' status has some advantages, it could catch more relations. But it looks like some relations could end up as 'proposed' for ever. And it is not clear why a 'proposed' state forever is useful.
Ian Hickson I'd be ok with this, but I think it would be even better to apply the proposal in http://lists.w3.org/Archives/Public/public-html/2011Mar/0497.html to this one.
Julian Reschke The main issue with this change proposal is that it doesn't unify relation types across protocols and document formats. Link relations apply to many non-HTML formats, and also occur as metadata outside documents, and should have a consistent meaning no matter where they show up. In particular, if they are not consistent than the specification will have to consider this when discussing the interaction between <link> and the HTTP Link header field.



Some more comments on the actual CP text, plus a few questions:

"1. The person registering a link relation can't have the relation appear in the registry with a single registration action but is on the hook for defending his/her registration over the course of multiple email round trips to the Designated Experts and during this time the relation doesn't appear in the registry."

Yes, there's no provisional registry. But there is an issue tracker that can be used to track registrations that are work-in-progress (see <http://paramsr.us/tracker/>).

"2. Registrations in the IANA registry are requested to be generic beyond HTML. Requiring the person who is about to register a rel token for use in HTML formulate the definition of the token in more abstract terms raises the barrier for entry. There isn't general agreement that a higher level of abstraction and generality is worth the trouble."

That is indeed the most important issue in this discussion. I believe that having consistent definitions would be useful (for instance, when translating between formats), and that the additional work of defining the relation in a format-agnostic way is both small and worth the effort.

"3. Changing how the IETF/IANA operate to satisfaction seems to involve considerably more discussion and time than setting up an HTML-specific rel registry elsewhere."

It would be good to know in which way the CP author *expects* the registry to change. I believe 1) is addressed by the associated tracker. 2) is indeed the issue we should decide on.

Otherwise, this proposal makes a lot of sense if we indeed *do* decide that harmonization between formats using link relations is not important.

A few specific comments/questions on the technical part:

a) Is the W3C indeed *willing* to run registries? This seemed to be unclear when we discussed this as TPAC Lyon. If it is, I'll probably propose to move the meta/@name registry as well.

b) Is the software capable of supporting the machine readability use case that was mentioned?

c) My understanding is that users will be required to obtain a W3C "Public Account", which requires registering (with a real name), and may not be fully automated. This may indeed be a higher barrier than simply sending an email to the IANA link relations mailing list.
Roy Fielding
Danny Ayers
Tantek Çelik 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.
Theresa O'Connor We don't know if the W3C Membership is willing to commit technical or financial resources to running a rel value registry. (Remember, the XPointer specification didn't establish the XPointer registry, it simply reserved all short names to the W3C. The Director then sought and received AC approval to establish a registry.) That said, the advancement of the HTML spec along the recommendation track could be taken as agreement to run a registry from the Director and Membership.

XPointer schemes have generally been easy to register, and we see no reason to expect a new W3C registry to be substantially worse than its precedent.

If we adopt this Change Proposal, this WG should seek to have the IANA registry updated to explicitly disclaim that it should be used for HTML rel values.

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

Details

Responder Objections to the Change Proposal to use the microformats Wiki page for the registry
Jonas Sicking
Leif Halvard Silli This is the option that I would be absolutely least satisfied with. I appreciate the Microformats community. It is, in my view, *the* community that has done the most to hold the extension torch for plain HTML the highest. And, perhaps it just myself, hower I perceive Microformtas as more "private" than the RFC-based and W3C-based otpion. Both inside the the RFC-based option and the W3C option, the Microformats specs have a room. Whereas it is not as clear to me how IETF/IANA and W3C have a room inside Microformats. Also, while the CP speaks about provisional registration, where does it speak about formal registration? Can a W3 spec speciy a link relation without it getting into the Microformats registry? Just because Microformats serves well as a specification development platform does not mean that it serves well as a registry. I also doubt that each and all of its specs are given much heed to. Take for exampel nofollow. Did it not appear in Google somewhere first? The Microformats spec is just a post-blessing. This hints that it is not a place which potential registrants 'default' to use when they want to register something. (It might be a place some default to use to *develop*, but not for registering.) One should keep specification and registration separate as this ensures that registration can be taken from more sources - it should not need to become a Microformats spec before it can be registred. Both the other two options maintain such a separation between specs and registry.
Ian Hickson I'd be ok with this too, especially in conjunction with the proposal in http://lists.w3.org/Archives/Public/public-html/2011Mar/0497.html (idem).
Julian Reschke The main issue with this change proposal is that it doesn't unify relation types across protocols and document formats. Link relations apply to many non-HTML formats, and also occur as metadata outside documents, and should have a consistent meaning no matter where they show up. In particular, if they are not consistent than the specification will have to consider this when discussing the interaction between <link> and the HTTP Link header field.

This could be addressed by the Microformats community embracing a broader view of link relations, but as far as I know, nobody has made a concrete proposal for that (nor could this WG tell the Microformats community what to do).

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

Additional comments:

On License -- "The registry we adopt should be available under a license compatible with both Free and proprietary software. The existing-rel-values page of the Microformats wiki is in the public domain, and as such its contents are able to be incorporated into Free software as well as proprietary software." -> I'm not aware of any concrete problem of using the contents of an IANA registry.

"Must be able to register HTML-specific details" --> see ISSUE-124 and <http://www.ietf.org/mail-archive/web/link-relations/current/msg00182.html>; so this is work-in-progress as of last weekend.

Furthermore, this CP contains a set of misunderstandings that I pointed out last December, see <http://lists.w3.org/Archives/Public/public-html/2010Dec/0112.html> (and please consider that mail as part of my feedback). As far as I can tell, that mail didn't get any feedback from Edward.
Roy Fielding The page

http://microformats.org/wiki/existing-rel-values

defines relation names in terms of recent HTML practice and specs, mostly microformat specs. All prior HTML practice and Web relations are either missing or incorrectly defined in that page.

Relation names are not media-type specific, and they have been around a lot longer than the source documents being used for that page. See, for example

http://www.csd.uwo.ca/~jamie/.Refs/LinkTypes/
http://www.w3.org/Architecture/NOTE-link.html

XFN foolishly redefines many common relations (e.g., "child") and that page incorrectly treats XFN as authoritative (as opposed to listing all of the specifications that have defined "child"). It should be no surprise, therefore, that people outside of the microformats community do not consider it a valid registry of names for the Internet in general -- not even for HTML's use.

In fact, the registry at

http://www.iana.org/assignments/link-relations/link-relations.xml

is already more complete and accurate than the microformats page.
It is proof, even with a very short existence, that IANA can be used as a registry for link relations and is far more reliable in doing so than the microformat wiki because it does not prefer microformats over all other link-defining hypertext.

From an architectural perspective, I strongly object to any notion that link relations are specific to a media type. They are orthogonal in Web architecture (always have been and always will be). Browser behavior given the presence of a link might be specific to some relations, but even that behavior would remain the same when the browser is rendering or following the links in some other media type that supports hypertext (e.g., PDF). Specific browser behavior can be defined in the HTML5 spec, with reference to known link relations, without defining HTML5 (or some wiki) as the source of truth for all link relations.
Danny Ayers
Tantek Çelik 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.
Theresa O'Connor If we adopt this Change Proposal, this WG should seek to have the IANA registry updated to explicitly disclaim that it should be used for HTML rel values.

With Apple hat off and author of this Change Proposal on, please see this email to public-html for my responses to objections: http://lists.w3.org/Archives/Public/public-html/2011Apr/0010.html

More details on responses

  • Jonas Sicking: last responded on 21, March 2011 at 23:20 (UTC)
  • Leif Halvard Silli: last responded on 22, March 2011 at 11:41 (UTC)
  • Ian Hickson: last responded on 23, March 2011 at 21:36 (UTC)
  • Julian Reschke: last responded on 28, March 2011 at 12:47 (UTC)
  • Roy Fielding: last responded on 30, March 2011 at 16:39 (UTC)
  • Danny Ayers: last responded on 1, April 2011 at 09:24 (UTC)
  • Tantek Çelik: last responded on 2, April 2011 at 01:18 (UTC)
  • Theresa O'Connor: last responded on 2, April 2011 at 01:36 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.