Results of Questionnaire ISSUE-127: Simplify characterization of link types - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-04 to 2011-03-11.

4 answers have been received.

Jump to results for question:

  1. Objections to define link types to have the same semantics independent of the element on which they appear
  2. Objections to optimize the spec's editorial style for legibility.

1. Objections to define link types to have the same semantics independent of the element on which they appear

We have a Change Proposal to define link types to have the same semantics independent of the element on which they appear. 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.


Responder Objections to define link types to have the same semantics independent of the element on which they appear
Ian Hickson * Fundamentally, the change here is editorial, and should be left up to editorial discretion. The suggested change is to a non-normative table, and despite claims to the contrary in the change proposal, the change will do nothing to actually affect how future link relations are designed.
* There is no "goal to make link relations handling inside HTML consistent with link relations in other contexts". There is no particular benefit or use case to making link relations consistent between Atom and HTML. The two technologies are distinct and do not share link handling logic, even when a single software package implements both.
* The proposal claims to simplify the spec by removing a degree of freedom, but even if the section it proposed to change was normative, in practice it merely trades one degree of freedom (the ability for a relationship on <link> to be defined differently than on <a>) for two others (the ability for a link relation to be allowed on <area> but not on <a>, and the ability for a link relation to have an effect on an element but not be allowed on that element), which would be a net increase in useless degrees of freedom, not a net decrease.
* The ability for a link relationship to be allowed on <area> but not <a> has no use case and would be more confusing than a link relationship having different meaning on <link> and <a>, since <a> and <area> are interchangeable in a way that <link> and <a> are not.
* A disallowed link relationship having a defined effect is not something that should be encouraged. If it is needed, it would be better to handle it as a special case in prose, since that would not give the appearance of it being a regular expected occurrence.
Aryeh Gregor I object to allowing people to waste the Working Group's time with issues that are purely aesthetic. Discussing whether a particular example is misleading, or what exact normative reference we should use for something, at least makes some theoretical difference to someone. But there is no credible claim anywhere in this Change Proposal that the proposed change, by itself, will make any difference to anyone or anything now or in the future.

There are a few places that look like they might argue for some benefit to adopting the change, but they don't stand up to scrutiny:

1) "The semantics of a link relation should not vary too much depending on where it appears." But as the Change Proposal itself points out, the semantics of all existing link relations in the spec do not vary at all depending on where they appear, either before or after this change. Thus this is not an argument in favor of the change.

2) "to encourage consistent semantics across elements". How will this result from the change? Is the proposer arguing that after adopting the change, the editor will be less likely to introduce new link types with inconsistent semantics across elements? (As I read the proposal, it doesn't prevent the editor from introducing such relations later if he likes.) No evidence or reasoning is presented to support this point, so it should be disregarded.

3) "to simplify the spec", "Removal of an unused degree of freedom in defining link relations". These are purely aesthetic benefits, whose merits are entirely debatable, and are in fact debated by the editor. We should not allow Change Proposals to be based on entirely subjective aesthetic judgments, only on quantifiable technical arguments. Even if we were to permit aesthetic arguments, however, there is no actual argument presented for why this simplification or removal of freedom is a good thing. We are asked to accept this as self-evident, but it's actually contested, so arguments must be presented in favor for it to be considered.

4) "consistency with link relations in other contexts." No explanation is given for why the change would increase consistency with link relations in other contexts. HTTP and Atom are mentioned, but no explanation is given of how link relations are treated by HTTP or Atom, or what relevance the proposed change has. Since the proposed change would (by the proposer's own admission) have no impact on how any of the link relations in HTML function, and is merely a change to how the existing functionality is presented, it's hard to imagine how it could improve consistency with anything. Fortunately, we are not tasked with using our imagination here, and should again reject this point for failing to present supporting evidence.

I could not find any other purported benefits of the change. Thus in summary, there are five claimed benefits, and none of them have any supporting arguments at all. It's not just that the supporting arguments are weak, they aren't present. The absence of any arguments in favor of the change means that we maintain the status quo.

I encourage the chairs to make it clear that Change Proposals will not be adopted if they merely assert that some way of phrasing or presenting things is clearer or simpler or easier to read, even if they invoke trivial arguments such as "shorter things are easier to read". Such changes are not going to bring any benefit that comes close to outweighing the effort expended in processing them, and will unduly delay progress along the Recommendation track. No other W3C Working Group that I'm aware of will even consider such objections -- thus the term "editorial issue". Editorial issues should only be subject to oversight if there's an argument that they could meaningfully mislead or harm readers of the spec.
Julian Reschke
Theresa O'Connor There are existing HTML rel values that have different behavior on <link> versus <a>. This degree of freedom is actually needed for several defined link relations, namely those that impact the loading of external resources when used on <link> but not on <a>. So this Change Proposal is incorrect when it claims otherwise.

The Change Proposal claims that distinguishing between rel values on <link> and on <a> conflicts with the goal of convergence with HTTP and Atom link relations. This goal does not (yet) have consensus in the Working Group, and is part of ISSUE-27. In only one of the potential resolutions to ISSUE-27 (adopting the IANA registry) does the current spec's table even potentially become a problem. Should ISSUE-27 go that way, we could always revisit this at that time. But, if ISSUE-27 is resolved in favor of *any of its other Change Proposals*, the change proposed here would result in wasted editor time that could have been more constructively spent elsewhere.

2. Objections to optimize the spec's editorial style for legibility.

We have a Change Proposal to optimize the spec's editorial style for legibility. If you have strong objections to adopting this Change Proposal specifically with respect to the figure element, 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.


Responder Objections to optimize the spec's editorial style for legibility.
Ian Hickson
Aryeh Gregor
Julian Reschke I object to the Counter Proposal for the reasons given in the Change Proposal. See also my comments in http://lists.w3.org/Archives/Public/public-html/2011Mar/0139.html and http://lists.w3.org/Archives/Public/public-html/2011Mar/0242.html.
Theresa O'Connor

More details on responses

  • Ian Hickson: last responded on 4, March 2011 at 20:53 (UTC)
  • Aryeh Gregor: last responded on 6, March 2011 at 01:51 (UTC)
  • Julian Reschke: last responded on 10, March 2011 at 16:55 (UTC)
  • Theresa O'Connor: last responded on 11, March 2011 at 22:53 (UTC)


The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <pion@umich.edu>
  3. Judy Brewer <jbrewer@w3.org>
  4. Liam Quin <liam@w3.org>
  5. Richard Ishida <ishida@w3.org>
  6. Chris Wilson <cwilso@google.com>
  7. David Carlisle <davidc@nag.co.uk>
  8. James Helman <jhelman@movielabs.com>
  9. Jim Allan <jimallan@tsbvi.edu>
  10. Chris Marrin <cmarrin@apple.com>
  11. Charles McCathie Nevile <chaals@yandex.ru>
  12. Philippe Le Hégaret <plh@w3.org>
  13. Don Brutzman <brutzman@nps.edu>
  14. T.V. Raman <raman@google.com>
  15. David Singer <singer@apple.com>
  16. Daniel Glazman <daniel.glazman@disruptive-innovations.com>
  17. Karl Dubost <karl@la-grange.net>
  18. Wu Chou <wu.chou@huawei.com>
  19. Katsuhiko Momoi <momoi@google.com>
  20. Kangchan Lee <chan@w3.org>
  21. Roy Fielding <fielding@gbiv.com>
  22. Deborah Dahl <dahl@conversational-technologies.com>
  23. Michael Cooper <cooper@w3.org>
  24. Glenn Adams <glenn@skynav.com>
  25. Jonathan Jeon <hollobit@etri.re.kr>
  26. David Hyatt <hyatt@apple.com>
  27. WonSuk Lee <wonsuk.lee@etri.re.kr>
  28. Maciej Stachowiak <mjs@apple.com>
  29. Robert Accettura <robert@accettura.com>
  30. Jonathan Watt <jwatt@jwatt.org>
  31. Steve Faulkner <faulkner.steve@gmail.com>
  32. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  33. Patrick Lauke <redux@splintered.co.uk>
  34. David MacDonald <David100@sympatico.ca>
  35. Jack Jansen <jack@cwi.nl>
  36. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  37. Markku Hakkinen <mhakkinen@ets.org>
  38. Jens Oliver Meiert <jens@meiert.com>
  39. Kazuyuki Ashimura <ashimura@w3.org>
  40. Han Xu <collin@w3china.org>
  41. Sam Ruby <rubys@intertwingly.net>
  42. Mark Crawford <mark.crawford@sap.com>
  43. Preety Kumar <preety.kumar@deque.com>
  44. Ian Fette <ifette@google.com>
  45. Cameron McCormack <cam@mcc.id.au>
  46. Stefan Schnabel <stefan.schnabel@sap.com>
  47. Jirka Kosek <jirka@kosek.cz>
  48. Travis Leithead <Travis.Leithead@microsoft.com>
  49. Youngsun Ryu <ysryu@samsung.com>
  50. Sierk Bornemann <sierkb@gmail.com>
  51. James Graham <james@hoppipolla.co.uk>
  52. Henri Sivonen <hsivonen@hsivonen.fi>
  53. Krijn Hoetmer <w3c@qontent.nl>
  54. Channy Yun <channy@gmail.com>
  55. Shane Thacker <shanethacker@gmail.com>
  56. Vilem Malek <murphy@malek.cz>
  57. Zhihong Mao <zhihong.mao@gmail.com>
  58. Benoit Piette <benoit.piette@gmail.com>
  59. Erik van Kempen <erikvankempen@gmail.com>
  60. Dimitri Glazkov <dglazkov@google.com>
  61. Nick Fitzsimons <w3@nickfitz.co.uk>
  62. Josh Lawton <w3c@joshlawton.com>
  63. S Emerson <w3c@accretewebsolutions.ca>
  64. Justin Anthony Knapp <justinkoavf@gmail.com>
  65. Simon Myers <Smylers@stripey.com>
  66. Samuel Weinig <weinig@apple.com>
  67. Alexey Proskuryakov <ap@webkit.org>
  68. Alejandro Fernandez <alejandro@mediadvanced.com>
  69. Doug Jones <doug_b_jones@me.com>
  70. Marc Drumm <mdrumm@wcupa.edu>
  71. Danny Liang <danny.glue@gmail.com>
  72. Michael Puls II <shadow2531@gmail.com>
  73. Ron Reisor <ron@udel.edu>
  74. Craig Buckler <craigbuckler@gmail.com>
  75. Dale Hudjik <dale.hudjik@gmail.com>
  76. James Cassell <w3c@cyberpear.com>
  77. Joseph D'Andrea <jdandrea@gmail.com>
  78. Eric Carlson <eric.carlson@apple.com>
  79. Don Kiely <donkiely@computer.org>
  80. David Child <dave@addedbytes.com>
  81. Mark DuBois <Mark@webprofessionals.org>
  82. David Bills <w3@dfbills.com>
  83. Nik Thierry <me@thisemail.ca>
  84. Andrew Ramsden <andrew@irama.org>
  85. John Foliot <john.foliot@deque.com>
  86. Shefik Macauley <allknightaccess@gmail.com>
  87. Joe Steele <steele@adobe.com>
  88. John Vernaleo <john@netpurgatory.com>
  89. Jeremy Keith <jeremy@adactio.com>
  90. Jedi Lin <JediLin@Gmail.com>
  91. Jon Hughes <jon@phazm.com>
  92. Samuel Santos <samaxes@gmail.com>
  93. Dean Jackson <dino@apple.com>
  94. Mohammed DADAS <mohammed.dadas@orange.com>
  95. Sally Cain <sally.cain@rnib.org.uk>
  96. David Bolter <dbolter@mozilla.com>
  97. James Craig <jcraig@apple.com>
  98. Leonard Rosenthol <lrosenth@adobe.com>
  99. Jean-Pierre EVAIN <evain@ebu.ch>
  100. Mark Pilgrim <pilgrim@google.com>
  101. Matt Lee <mattl@cnuk.org>
  102. Magnus Olsson <magnus.olsson@ericsson.com>
  103. Chris Pearce <cpearce@mozilla.com>
  104. Andrew Wilson <atwilson@google.com>
  105. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  106. Ojan Vafai <ojan@chromium.org>
  107. Martin McEvoy <martin@weborganics.co.uk>
  108. Anders Bondehagen <anders@bondehagen.com>
  109. Steven Pemberton <Steven.Pemberton@cwi.nl>
  110. Raul Hudea <rhudea@adobe.com>
  111. Raghavan Gurumurthy <raghavan@adobe.com>
  112. Mayank Kumar <mayankk@adobe.com>
  113. Dragos Georgita <dgeorgit@adobe.com>
  114. Christopher Bank <cbank@adobe.com>
  115. Ole Riesenberg <or@oleriesenberg.com>
  116. Takuya Oikawa <takuya@google.com>
  117. Jatinder Mann <jmann@microsoft.com>
  118. Robert Stern <rstern@gmail.com>
  119. Eihab Ibrahim <eihabibrahim@gmail.com>
  120. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  121. Jer Noble <jer.noble@apple.com>
  122. Masatomo Kobayashi <mstm@jp.ibm.com>
  123. Peter Beverloo <beverloo@google.com>
  124. Andrew Scherkus <scherkus@google.com>
  125. Greg Johnson <greg.johnson@gmail.com>
  126. Martijn Croonen <martijn@martijnc.be>
  127. Stanley Manoski <manoski@mitre.org>
  128. Mounir Lamouri <mlamouri@google.com>
  129. Tony Gentilcore <tonyg@google.com>
  130. Joseph Pecoraro <pecoraro@apple.com>
  131. Bob Lund <b.lund@cablelabs.com>
  132. Tatsuya Igarashi <Tatsuya.Igarashi@sony.com>
  133. John Simmons <johnsim@microsoft.com>
  134. Mark Watson <watsonm@netflix.com>
  135. Clarke Stevens <c.stevens@cablelabs.com>
  136. Mark Vickers <mark_vickers@comcast.com>
  137. Jeremy LaCivita <jeremy.lacivita@comcast.com>
  138. Denis Ah-Kang <denis@w3.org>
  139. Alvar Laigna <laigna@gmail.com>
  140. Kunio Ito <kunio.ito@mail.rakuten.com>
  141. David Mays <david_mays@comcast.com>
  142. Michael Chen <michael_chen@comcast.com>
  143. jongyoul Park <jongyoul@etri.re.kr>
  144. Reinaldo Ferraz <reinaldo@nic.br>
  145. Eva Lingyun Jing <jinglingyun@baidu.com>
  146. GANG LIANG <gang.liang@huawei.com>
  147. Ryosuke Niwa <rniwa@apple.com>
  148. Gian Luca Marroni <gmarroni@libero.it>
  149. Ian Devlin <ian@iandevlin.com>
  150. Xingrong Guo <guoxingrong@baidu.com>
  151. Jet Villegas <w3c@junglecode.net>
  152. Alexander Surkov <surkov.alexander@gmail.com>
  153. Hasan Savran <hsavran@kent.edu>
  154. Eric VonColln <eric.voncolln@navy.mil>
  155. Rayi Lei <leiyi@baidu.com>
  156. David Dorwin <ddorwin@google.com>
  157. jiexuan gao <gaojiexuan@baidu.com>
  158. Xiaoqing Yang <yangxiaoqing@baidu.com>
  159. Aaron Colwell <acolwell@google.com>
  160. Alex Giladi <alex.giladi@huawei.com>
  161. Motomasa Futagami <mares@paoz.net>
  162. Kevin Streeter <kstreete@adobe.com>
  163. Christian Kaiser <kaiserc@google.com>
  164. Xuejian Li <lixuejian@baidu.com>
  165. Zuncheng Yang <yangzuncheng@baidu.com>
  166. Qianglong Zheng <zhengqianglong@baidu.com>
  167. Zhou Shen <shenzhou@baidu.com>
  168. Duoyi Wu <wuduoyi@baidu.com>
  169. Zheng Jia <jiazheng@baidu.com>
  170. Weifeng Feng <fengweifeng@baidu.com>
  171. Damin Hu <hudamin@baidu.com>
  172. Yang Liu <liuyang12@baidu.com>
  173. Zhixing Lei <leizhixing@baidu.com>
  174. Honggang Tang <tanghonggang@baidu.com>
  175. Kefeng Li <buaadallas@gmail.com>
  176. Xu Ma <maxu@baidu.com>
  177. Junzhong Liu <liujunzhong@baidu.com>
  178. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  179. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  180. Ami Fischman <fischman@google.com>
  181. Arnaud Braud <arnaud.braud@orange.com>
  182. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  183. Bram Tullemans <tullemans@ebu.ch>
  184. Petr Peterka <ppeterka@verimatrix.com>
  185. lei wang <wanglei03@baidu.com>
  186. Milan Patel <Milan.Patel@huawei.com>
  187. Yiling Gu <guyiling@baidu.com>
  188. Zefa Xiong <xiongzefa@baidu.com>
  189. shanglin chen <chenshanglin@baidu.com>
  190. Ping Wu <wuping02@baidu.com>
  191. Bin Chen <chenbin01@baidu.com>
  192. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  193. Patrick Ladd <Pat_Ladd2@comcast.com>
  194. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  195. Hao Jing <jh.jinghao@huawei.com>
  196. Glenn Deen <glenn.deen@nbcuni.com>
  197. Lei Wang <wanglei@baidu.com>
  198. Tom Handal <thandal@verimatrix.com>
  199. Pengcheng Guo <guopengcheng@baidu.com>
  200. Tom Wiltzius <wiltzius@google.com>
  201. Pierre-Anthony Lemieux <pal@sandflow.com>
  202. Xie Jianhui <xiejianhui@baidu.com>
  203. Yujie Jiang <jiangyujie@baidu.com>
  204. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  205. Brady Eidson <beidson@apple.com>
  206. Michael Thornburgh <mthornbu@adobe.com>
  207. Mick Hakobyan <mhakobyan@netflix.com>
  208. Vladimir Sinelnikov <sinelnikov@gmail.com>
  209. Chris Wong <huanghoujin@baidu.com>
  210. Yiliang LIU <liuyiliang@baidu.com>
  211. mingqiang zhang <imcnan@gmail.com>
  212. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  213. Grzegorz Babula <gbabula@gmail.com>
  214. Brian Kardell <hitchjs@gmail.com>
  215. xueliang fan <fanxueliang@baidu.com>
  216. Niels Thorwirth <nthorwirth@verimatrix.com>
  217. David Evans <david.evans@rd.bbc.co.uk>
  218. Joseph Karr O'Connor <josephoconnor@mac.com>
  219. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  220. smallni ding <smallniding@tencent.com>
  221. Jim Walsh <jim@jwalshcreative.com>
  222. Greg Davis <greg.davis@pearson.com>
  223. Gabino Alonso <gabinovincent@gmail.com>
  224. Sam Langdon <sam.langdon@hachette.co.uk>
  225. Michael Kelly <mkelly@mozilla.com>
  226. Xiaoqian Wu <xiaoqian@w3.org>
  227. Yue Min <minyue@baidu.com>
  228. Min Li <limin04@baidu.com>
  229. Joanmarie Diggs <jdiggs@igalia.com>
  230. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  231. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  232. So Vang <svang@nab.org>
  233. Nathalia Sautchuk Patrício <nathalia@nic.br>
  234. Vicente García Díaz <vicegd@live.com>
  235. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  236. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  237. John Riviello <john_riviello@comcast.com>
  238. yaolong wang <wangyaolong@baidu.com>
  239. Tao Liang <liangtao01@baidu.com>
  240. Glenn Eguchi <geguchi@adobe.com>
  241. Lukáš Čihák <lukas.cihak@mensa.cz>
  242. WOOGLAE KIM <wlkim@inswave.com>
  243. Min Ren <minren@tencent.com>
  244. Jason White <jjwhite@ets.org>
  245. Hyejin Lee <hjlee@html5forum.or.kr>
  246. Richard Grzeczkowski <richard_grzeczkowski@comcast.com>
  247. Pascal Perrot <pascal.perrot@orange.com>
  248. Dapeng Liu <max.ldp@alibaba-inc.com>
  249. Matthew Wolenetz <wolenetz@google.com>
  250. Cory Heslip <cory_heslip@comcast.com>
  251. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  252. Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>
  253. Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>
  254. Ali C. Begen <ali_begen@comcast.com>
  255. HENGBING LIU <herbertliu@tencent.com>

Send an email to all the non-responders.

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 (preferred) or by mail to sysreq.