W3C WBS Home

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.

Details

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

Details

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.
Edward O'Connor

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Tantek Çelik <tantek@cs.stanford.edu>
  2. Patrick D F Ion <ion@ams.org>
  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-team.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. Larry Masinter <masinter@adobe.com>
  19. Lisa Seeman <lisa.seeman@zoho.com>
  20. Paul Cotton <Paul.Cotton@microsoft.com>
  21. Wu Chou <wu.chou@huawei.com>
  22. Katsuhiko Momoi <momoi@google.com>
  23. Kangchan Lee <chan@w3.org>
  24. Roy Fielding <fielding@gbiv.com>
  25. Silvia Pfeiffer <silviapfeiffer1@gmail.com>
  26. Johnny Stenback <jst@mozilla.com>
  27. Janina Sajka <janina@rednote.net>
  28. Deborah Dahl <dahl@conversational-technologies.com>
  29. Michael Cooper <cooper@w3.org>
  30. Glenn Adams <glenn@skynav.com>
  31. Jonathan Jeon <hollobit@etri.re.kr>
  32. David Hyatt <hyatt@apple.com>
  33. WonSuk Lee <wonsuk.lee@etri.re.kr>
  34. Maciej Stachowiak <mjs@apple.com>
  35. Robert Accettura <robert@accettura.com>
  36. Jonathan Watt <jwatt@jwatt.org>
  37. Steve Faulkner <faulkner.steve@gmail.com>
  38. Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>
  39. Patrick Lauke <redux@splintered.co.uk>
  40. David MacDonald <David100@sympatico.ca>
  41. Jack Jansen <jack@cwi.nl>
  42. Kazuhito Kidachi <k-kidachi@mitsue.co.jp>
  43. Markku Hakkinen <mhakkinen@ets.org>
  44. Cyril Concolato <cyril.concolato@telecom-paristech.fr>
  45. Jens Meiert <jens@meiert.com>
  46. Felix Sasaki <fsasaki@w3.org>
  47. Kazuyuki Ashimura <ashimura@w3.org>
  48. Tomas Caspers <tomas@tomascaspers.de>
  49. Han Xu <collin@w3china.org>
  50. Sam Ruby <rubys@intertwingly.net>
  51. Jonas Sicking <jonas@sicking.cc>
  52. Mark Crawford <mark.crawford@sap.com>
  53. Preety Kumar <preety.kumar@deque.com>
  54. Doug Schepers <schepers@w3.org>
  55. Ian Fette <ifette@google.com>
  56. Michael[tm] Smith <mike@w3.org>
  57. Cameron McCormack <cam@mcc.id.au>
  58. Stefan Schnabel <stefan.schnabel@sap.com>
  59. Jirka Kosek <jirka@kosek.cz>
  60. Travis Leithead <Travis.Leithead@microsoft.com>
  61. Youngsun Ryu <ysryu@samsung.com>
  62. Sierk Bornemann <sierkb@gmail.com>
  63. Martijn Wargers <martijn.martijn@gmail.com>
  64. Simon Pieters <simonp@opera.com>
  65. James Graham <james@hoppipolla.co.uk>
  66. Henri Sivonen <hsivonen@hsivonen.fi>
  67. Krijn Hoetmer <w3c@qontent.nl>
  68. Markus Fischer <markus@fischer.name>
  69. Channy Yun <channy@gmail.com>
  70. Shane Thacker <shanethacker@gmail.com>
  71. Bill Mason <billm@accessibleinter.net>
  72. Vilem Malek <murphy@malek.cz>
  73. Zhihong Mao <zhihong.mao@gmail.com>
  74. Benoit Piette <benoit.piette@gmail.com>
  75. Erik van Kempen <erikvankempen@gmail.com>
  76. Dimitri Glazkov <dglazkov@google.com>
  77. Nick Fitzsimons <w3@nickfitz.co.uk>
  78. Josh Lawton <w3c@joshlawton.com>
  79. Giovanni Gentili <giovanni.gentili@gmail.com>
  80. Adele Peterson <adele@apple.com>
  81. S Emerson <w3c@accretewebsolutions.ca>
  82. Morten Tollefsen <morten@medialt.no>
  83. Daniel Schattenkirchner <schattenkirchner.daniel@gmx.de>
  84. Justin Anthony Knapp <justinkoavf@gmail.com>
  85. Simon Myers <Smylers@stripey.com>
  86. Samuel Weinig <weinig@apple.com>
  87. Alexey Proskuryakov <ap@webkit.org>
  88. Alejandro Fernandez <alejandro@mediadvanced.com>
  89. Doug Jones <doug_b_jones@me.com>
  90. Marc Drumm <mdrumm@wcupa.edu>
  91. Danny Liang <danny.glue@gmail.com>
  92. Michael Puls II <shadow2531@gmail.com>
  93. Ron Reisor <ron@udel.edu>
  94. Marat Tanalin <mtanalin@yandex.ru>
  95. Andrew Norman <idonothaveacat@gmail.com>
  96. Craig Buckler <craigbuckler@gmail.com>
  97. Matthew Turvey <mcturvey@gmail.com>
  98. Dale Hudjik <dale.hudjik@gmail.com>
  99. James Cassell <w3c@cyberpear.com>
  100. Joseph D'Andrea <jdandrea@gmail.com>
  101. Eric Carlson <eric.carlson@apple.com>
  102. Michael Turnwall <w3c@turnwall.net>
  103. Don Kiely <donkiely@computer.org>
  104. Robert Marshall <rdm@rdmsoft.com>
  105. David Child <dave@addedbytes.com>
  106. Mark DuBois <Mark@webprofessionals.org>
  107. David Bills <w3@dfbills.com>
  108. Nik Thierry <me@thisemail.ca>
  109. Andrew Ramsden <andrew@irama.org>
  110. John Foliot <john.foliot@deque.com>
  111. Shefik Macauley <allknightaccess@gmail.com>
  112. Joe Steele <steele@adobe.com>
  113. John Vernaleo <john@netpurgatory.com>
  114. Jeremy Keith <jeremy@adactio.com>
  115. Jedi Lin <JediLin@Gmail.com>
  116. Jon Hughes <jon@phazm.com>
  117. Samuel Santos <samaxes@gmail.com>
  118. Dean Jackson <dino@apple.com>
  119. Mohammed DADAS <mohammed.dadas@orange.com>
  120. Sally Cain <sally.cain@rnib.org.uk>
  121. Dan Romascanu <dromasca@avaya.com>
  122. David Bolter <dbolter@mozilla.com>
  123. James Craig <jcraig@apple.com>
  124. MING JIN <ming.jin.web@gmail.com>
  125. Leonard Rosenthol <lrosenth@adobe.com>
  126. Adrian Bateman <adrianba@microsoft.com>
  127. Dionysios Synodinos <synodinos@gmail.com>
  128. Jean-Pierre EVAIN <evain@ebu.ch>
  129. Mark Pilgrim <pilgrim@google.com>
  130. Matt Lee <mattl@cnuk.org>
  131. Magnus Olsson <magnus.olsson@ericsson.com>
  132. Chris Pearce <cpearce@mozilla.com>
  133. Mark Miller <erights@google.com>
  134. Andrew Wilson <atwilson@google.com>
  135. Per-Erik Brodin <per-erik.brodin@ericsson.com>
  136. Ojan Vafai <ojan@chromium.org>
  137. Martin McEvoy <martin@weborganics.co.uk>
  138. Jonathan Griffin <jgriffin@mozilla.com>
  139. Anders Bondehagen <anders@bondehagen.com>
  140. Steven Pemberton <Steven.Pemberton@cwi.nl>
  141. Raul Hudea <rhudea@adobe.com>
  142. Raghavan Gurumurthy <raghavan@adobe.com>
  143. Mayank Kumar <mayankk@adobe.com>
  144. Monikandan S <smonikan@adobe.com>
  145. Dragos Georgita <dgeorgit@adobe.com>
  146. Christopher Bank <cbank@adobe.com>
  147. Ole Riesenberg <or@oleriesenberg.com>
  148. Takuya Oikawa <takuya@google.com>
  149. Jatinder Mann <jmann@microsoft.com>
  150. Robert Stern <rstern@gmail.com>
  151. Dean Leigh <dean.leigh@deanleigh.co.uk>
  152. Eihab Ibrahim <eihabibrahim@gmail.com>
  153. Kensaku KOMATSU <kensaku.komatsu@gmail.com>
  154. Jer Noble <jer.noble@apple.com>
  155. Masatomo Kobayashi <mstm@jp.ibm.com>
  156. Grant Simpson <glsimpso@gmail.com>
  157. Peter Beverloo <beverloo@google.com>
  158. Andrew Scherkus <scherkus@google.com>
  159. Greg Johnson <greg.johnson@gmail.com>
  160. Martijn Croonen <martijn@martijnc.be>
  161. Stanley Manoski <manoski@mitre.org>
  162. Jonas Schneider <js.sokrates@gmail.com>
  163. Yosuke Funahashi <yosuke@w3.org>
  164. Mounir Lamouri <mlamouri@google.com>
  165. Mike Amundsen <mamund@yahoo.com>
  166. Tony Gentilcore <tonyg@google.com>
  167. Joseph Pecoraro <pecoraro@apple.com>
  168. Othmane Benyoucef <othmane_benyoucef@hotmail.com>
  169. Shoko Okuma <okuma@tomo-digi.co.jp>
  170. Fumitaka Watanabe <fwtnb@tomo-digi.co.jp>
  171. Yoshimitsu Tsurimaki <tsurimaki@tomo-digi.co.jp>
  172. Bob Lund <b.lund@cablelabs.com>
  173. Tatsuya Igarashi <Tatsuya.Igarashi@jp.sony.com>
  174. John Simmons <johnsim@microsoft.com>
  175. Mathias Bynens <mathias@qiwi.be>
  176. Mark Watson <watsonm@netflix.com>
  177. Clarke Stevens <c.stevens@cablelabs.com>
  178. Mark Vickers <mark_vickers@cable.comcast.com>
  179. Sree Kotay <Sree_Kotay@cable.comcast.com>
  180. Cameron Jones <cmhjones@gmail.com>
  181. Rik Cabanier <Cabanier@adobe.com>
  182. Jeremy LaCivita <jeremy.lacivita@theplatform.com>
  183. Denis Ah-Kang <denis@w3.org>
  184. Alvar Laigna <laigna@gmail.com>
  185. Kunio Ito <kunio.ito@mail.rakuten.com>
  186. David Mays <david_mays@comcast.com>
  187. Michael Chen <michael_chen@cable.comcast.com>
  188. jongyoul Park <jongyoul@etri.re.kr>
  189. Adrian Roselli <aroselli@gmail.com>
  190. Colin Ihrig <cjihrig@gmail.com>
  191. Kilroy Hughes <kilroy.hughes@microsoft.com>
  192. Reinaldo Ferraz <reinaldo@nic.br>
  193. Bill Mandel <bill.mandel@nbcuni.com>
  194. Eva Lingyun Jing <jinglingyun@baidu.com>
  195. GANG LIANG <gang.liang@huawei.com>
  196. Ryosuke Niwa <rniwa@apple.com>
  197. Jason Kiss <jason@accessibleculture.org>
  198. Gian Luca Marroni <gmarroni@libero.it>
  199. Ian Devlin <ian@iandevlin.com>
  200. Xingrong Guo <guoxingrong@baidu.com>
  201. Jet Villegas <w3c@junglecode.net>
  202. Alexander Surkov <surkov.alexander@gmail.com>
  203. Hasan Savran <hsavran@kent.edu>
  204. Marco Kotrotsos <Marco@mlabs.nl>
  205. Eric VonColln <eric.voncolln@navy.mil>
  206. Jason Boyd <jason@pixelboxdesign.co.uk>
  207. Jungkee Song <jungkee.song@samsung.com>
  208. Rayi Lei <leiyi@baidu.com>
  209. Daniel Austin <daniel.austin@grintech.net>
  210. David Dorwin <ddorwin@google.com>
  211. jiexuan gao <gaojiexuan@baidu.com>
  212. Mathew Marquis <mat@matmarquis.com>
  213. Xiaoqing Yang <yangxiaoqing@baidu.com>
  214. Aaron Colwell <acolwell@google.com>
  215. Alex Giladi <alex.giladi@huawei.com>
  216. Motomasa Futagami <Motomasa.Futagami@jp.sony.com>
  217. Kevin Streeter <kstreete@adobe.com>
  218. Christian Kaiser <kaiserc@google.com>
  219. Xuejian Li <lixuejian@baidu.com>
  220. Zuncheng Yang <yangzuncheng@baidu.com>
  221. Qianglong Zheng <zhengqianglong@baidu.com>
  222. Zhou Shen <shenzhou@baidu.com>
  223. Duoyi Wu <wuduoyi@baidu.com>
  224. Zheng Jia <jiazheng@baidu.com>
  225. Weifeng Feng <fengweifeng@baidu.com>
  226. Damin Hu <hudamin@baidu.com>
  227. Yang Liu <liuyang12@baidu.com>
  228. Zhixing Lei <leizhixing@baidu.com>
  229. Honggang Tang <tanghonggang@baidu.com>
  230. Kefeng Li <buaadallas@gmail.com>
  231. Xu Ma <maxu@baidu.com>
  232. Junzhong Liu <liujunzhong@baidu.com>
  233. Yusuke Maehama <maehama@tomo-digi.co.jp>
  234. Stefan Kaiser <stefan.kaiser@fokus.fraunhofer.de>
  235. Sheau Ng <Sheau.ng@nbcuni.com>
  236. Stefan Pham <stefan.pham@fokus.fraunhofer.de>
  237. Ami Fischman <fischman@google.com>
  238. Arnaud Braud <arnaud.braud@orange.com>
  239. Futomi Hatano <futomi.hatano@newphoria.co.jp>
  240. Bram Tullemans <tullemans@ebu.ch>
  241. Petr Peterka <ppeterka@verimatrix.com>
  242. lei wang <wanglei03@baidu.com>
  243. Milan Patel <Milan.Patel@huawei.com>
  244. Yiling Gu <guyiling@baidu.com>
  245. Zefa Xiong <xiongzefa@baidu.com>
  246. shanglin chen <chenshanglin@baidu.com>
  247. Yaso Córdova <yaso@nic.br>
  248. Ping Wu <wuping02@baidu.com>
  249. Bin Chen <chenbin01@baidu.com>
  250. Youichi Takashima <takashima.youichi@lab.ntt.co.jp>
  251. Patrick Ladd <Pat_Ladd2@cable.comcast.com>
  252. Norifumi Kikkawa <norifumi.kikkawa@jp.sony.com>
  253. Hanrui Gao <gaohanrui@360.cn>
  254. Hao Jing <jh.jinghao@huawei.com>
  255. Glenn Deen <glenn.deen@nbcuni.com>
  256. Lei Wang <wanglei@baidu.com>
  257. Tom Handal <thandal@verimatrix.com>
  258. Tsutomu Ogasawara <tsutomu.ogasawara@mail.rakuten.com>
  259. Jose Segura <jose.segura@mail.rakuten.com>
  260. Pengcheng Guo <guopengcheng@baidu.com>
  261. Tom Wiltzius <wiltzius@google.com>
  262. Pierre-Anthony Lemieux <pal@sandflow.com>
  263. Xie Jianhui <xiejianhui@baidu.com>
  264. Yujie Jiang <jiangyujie@baidu.com>
  265. Leslie Sikos <sikos@sikoswebconsulting.com.au>
  266. Mark Sadecki <mark@sadecki.com>
  267. Kazuhiko Takabayashi <kazuhiko.takabayashi@jp.sony.com>
  268. Brady Eidson <beidson@apple.com>
  269. Jerry Smith <jdsmith@microsoft.com>
  270. Michael Thornburgh <mthornbu@adobe.com>
  271. Cyril Rickelton-Abdi <cyril.rickelton-abdi@turner.com>
  272. Andrew Davis <andrew@diff.mx>
  273. Mick Hakobyan <mhakobyan@netflix.com>
  274. Vladimir Sinelnikov <sinelnikov@gmail.com>
  275. Chris Wong <huanghoujin@baidu.com>
  276. Yiliang LIU <liuyiliang@baidu.com>
  277. Hernan Beati <hernanbeati@gmail.com>
  278. mingqiang zhang <imcnan@gmail.com>
  279. yubo zhou <zhouyubo@360.cn>
  280. Ben Barber <barberboy@gmail.com>
  281. Suzanne Taylor <Suzanne.Taylor@pearson.com>
  282. Grzegorz Babula <gbabula@gmail.com>
  283. Brian Kardell <hitchjs@gmail.com>
  284. xueliang fan <fanxueliang@baidu.com>
  285. Niels Thorwirth <nthorwirth@verimatrix.com>
  286. David Evans <david.evans@rd.bbc.co.uk>
  287. Danny O'Brien <danny@eff.org>
  288. Joseph Karr O'Connor <josephoconnor@mac.com>
  289. Seth Schoen <schoen@eff.org>
  290. Yusuke Kagiwada <block.rxckin.beats@gmail.com>
  291. smallni ding <smallniding@tencent.com>
  292. Jamil Ellis <jamil.ellis@hbo.com>
  293. Jim Walsh <jim@jwalshcreative.com>
  294. Greg Davis <greg.davis@pearson.com>
  295. Gabino Alonso <gabinovincent@gmail.com>
  296. Sam Langdon <sam.langdon@hachette.co.uk>
  297. Michael Kelly <mkelly@mozilla.com>
  298. Xiaoqian Wu <xiaoqian@w3.org>
  299. Yue Min <minyue@baidu.com>
  300. Min Li <limin04@baidu.com>
  301. A.S. Krishnakumar <ask@avaya.com>
  302. Jonathan Neal <jonathantneal@gmail.com>
  303. Joanmarie Diggs <jdiggs@igalia.com>
  304. Pedro Xavier Jorge <pedro.xavierjorge@gmail.com>
  305. Akira Torii <Torii.Akira@bp.MitsubishiElectric.co.jp>
  306. So Vang <svang@nab.org>
  307. Nathalia Sautchuk Patrício <nathalia@nic.br>
  308. Deblyn prado <deblyn@nic.br>
  309. Vicente García Díaz <vicegd@live.com>
  310. Nolan Butcher <nolan.butcher@hbo.com>
  311. Shinya Maruyama <Shinya.Maruyama@jp.sony.com>
  312. RAVI CHANDRA RAVULAPATI <ravichandra480@gmail.com>
  313. Yusuke Yokosuka <Yokosuka.Yusuke@bx.MitsubishiElectric.co.jp>
  314. John Riviello <john_riviello@comcast.com>
  315. yaolong wang <wangyaolong@baidu.com>
  316. Tao Liang <liangtao01@baidu.com>
  317. Glenn Eguchi <geguchi@adobe.com>
  318. Chockalingam Muthian <chockam@gmail.com>
  319. Lukáš Čihák <lukas.cihak@mensa.cz>
  320. WOOGLAE KIM <wlkim@inswave.com>
  321. Min Ren <minren@tencent.com>
  322. Rustam Khashimkhodjaev <Rustam_Khashimkhodjaev@cable.comcast.com>
  323. Jason White <jjwhite@ets.org>
  324. Hyejin Lee <hjlee@html5forum.or.kr>
  325. Richard Grzeczkowski <richard_grzeczkowski@cable.comcast.com>
  326. qigang huang <qiganghuang@tencent.com>
  327. Pascal Perrot <pascal.perrot@orange.com>
  328. Dapeng Liu <max.ldp@alibaba-inc.com>
  329. Matthew Wolenetz <wolenetz@google.com>
  330. Cory Heslip <cory_heslip@cable.comcast.com>
  331. Shaohang Yang <shaohang.ysh@alibaba-inc.com>
  332. Pramod Patlolla <pramod.patlolla@turner.com>
  333. Cooper Pope <cooper.pope@turner.com>
  334. Choon-Sik Cho <admin@wizvera.com>
  335. Seiji Okumura <Okumura.Seiji@bc.MitsubishiElectric.co.jp>
  336. Eiji Yamamoto <Yamamoto.Eiji@db.MitsubishiElectric.co.jp>

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


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.132 2015/11/30 15:46:52 carcone Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)