[1] [CITE@en-US[David Baron's weblog: March 2007]] ([CODE[2007-03-25 14:52:46 +09:00]] 版) ([[名無しさん]] [WEAK[2007-03-25 05:54:29 +00:00]]) [2] [CITE@en-US[David Baron's weblog: March 2007]] ([CODE[2007-03-25 14:52:46 +09:00]] 版) ([[名無しさん]] [WEAK[2007-03-25 06:14:58 +00:00]]) [3] [CITE[The Norwegians get it! - O'Reilly XML Blog]] ([[Rick Jelliffe]] 著, [CODE[2007-05-17 20:37:56 +09:00]] 版) ([[名無しさん]] [WEAK[2007-05-17 11:39:07 +00:00]]) [4] [CITE[Wasting resources - Anne’s Weblog]] ([TIME[2007-05-20 06:46:44 +09:00]] 版) ([[名無しさん]] [WEAK[2007-05-20 01:43:35 +00:00]]) [5] [CITE@en['''['''cs/0105018''']''' HTTP Cookies: Standards, Privacy, and Politics]] ([TIME[2005-09-17 23:32:47 +09:00]] 版) [7] [[Cookie]] の [[IETF]] における標準化の歴史と、いかにそれが失敗したかを中の人が振り返った論文です。 議論の長期化によってタイミングを逃したこと、利害関係者を集めることに失敗して誰も興味を持たない標準が生まれたこと、 理想と政治に振り回されて現実とかけ離れた結論が導かれたことなど、 大変興味深いものです。 [6] [CITE[Re: '''['''http-state''']''' Goals for the UA conformance section (was Re: Updated draft)]] ([TIME[2009-08-19 16:10:45 +09:00]] 版) > In general, specs should be specific about what the output should be. We shouldn't leave things undefined or up to the implementation if it affects other implementations (such as servers), because otherwise we will find authors end up relying on the market leader's behaviour. [8] 細部を未定義のままとしておくことは、実装の自由度が増し、最適化などの余地が生まれることで利用者にとってもメリットが増えると思えます。 しかし実はそれが成り立つのは、その未定義な動作の影響が閉じていて観察できない時に限られます。 たとえ仕様上未定義であっても、ほとんどの人は仕様がどうであるかではなく、主要な実装がどう動いているかに基づき行動します。 結果として、「未定義」は「市場のリーダーに倣え」の意味となり、標準の存在意義を危ぶむこととなるのです。 [9] [CITE[Re: '''['''http-state''']''' Goals for the UA conformance section (was Re: Updated draft)]] ([TIME[2009-08-20 00:10:08 +09:00]] 版) >We're documenting (or should be documenting, IMHO) what all implementations are going to converge on. That means describing what they do when they do the same thing, and considering differences to be bugs for which we are to find solutions that are acceptable to implementors. [10] [CITE[IRC logs: freenode / #whatwg / 20090727]] ([TIME[2009-09-27 21:53:01 +09:00]] 版) > -[10:49] proposing spec text is a terrible way to contribute to spec development, in my experience -[10:49] because unless you're truly familiar with the spec, you'll miss all kinds of things -[10:50] best to propose use cases, requirements [11] [CITE@en[(X)HTML5 Tracking]] ([TIME[2009-09-29 23:48:37 +09:00]] 版) [12] [CITE[IRC logs: freenode / #whatwg / 20090803]] ([TIME[2009-10-04 14:33:21 +09:00]] 版) >[14:23] adactio: browser implementation reqs are the most reality-based and the non-machine-detectable conformance reqs are the least reality based parts of the spec [13] [CITE[IRC logs: freenode / #whatwg / 20090818]] ([TIME[2009-10-12 16:14:46 +09:00]] 版) > - [03:25] * Hixie wonders why adding features to the web platform feels like a continuous exercise in damage mitigation - [03:25] it's like trying to build a sandcastle under a waterfall - [03:26] lol. And you have four large, powerful groups of people all telling you that they don't like the shape of your crenelations. - [03:26] fan more than four - [03:27] far, even - [03:27] there's the IETF people, the accessibility people, microsoft, google, apple, mozilla, opera, the TAG, the RDFa people... - [03:27] Yeah. I'm only just beginning to get into this, but...I don't envy that. - [03:28] eh, the sad thing is i enjoy it - [03:28] i'm a sucker i guess :-P [14] [CITE[IRC logs: freenode / #whatwg / 20090909]] ([TIME[2009-10-18 18:18:41 +09:00]] 版) > [09:29] tantek: the intent of the person writing teh spec is irrelevant to what the spec means. Only the spec, and what the spec references normatively, are relevant. Unless the spec says that a human can override it, no human can override it.