- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 26 Mar 2012 16:52:07 -0600
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CACQ=j+eT59Mw90HParkDWtjia=5oJAb-3jsOGfOO=gtgpEUyKA@mail.gmail.com>
On Mon, Mar 26, 2012 at 4:43 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Mon, Mar 26, 2012 at 1:40 PM, Glenn Adams <glenn@skynav.com> wrote: > > It has been stated to me that, at least for "open web platform > standards", > > the following statement is true and is shared by the majority: > > > > "if it isn't written in the spec, it isn't allowed by the spec" > > > > I happen to disagree with the truth of this, based on my personal > experience > > both with spec writing and with implementation/use of specs, but I would > be > > curious to see who agrees with this idea or not. > > > > The case in point is an instance of a possible ambiguity in a spec > because a > > particular assumption/convention is not documented; i.e., an assumption > that > > something isn't allowed even though it isn't explicitly disallowed. > While I > > agree it is, in general, impossible (or at least impractical) to document > > all disallowances, I do believe it is important to document important > > disallowances, particular when there are concerns raised about spec > > ambiguity. > > The statement you quoted is more or less accurate. Behavior that > isn't specced is almost certain to not be interoperable. If the spec > is incomplete or unclear in some aspect, that's a spec bug, not an > opportunity for implementations to make up their own behavior based on > what the engineer thinks is reasonable at the time they're writing the > code. > however, that is exactly what implementers do every day... especially those not closely connected with the spec process
Received on Monday, 26 March 2012 22:52:55 UTC