- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 22 Apr 2013 10:53:31 +0100
- To: Rand McRanderson <therandshow@gmail.com>
- Cc: Larry Masinter <masinter@adobe.com>, Marcos Caceres <w3c@marcosc.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Ian Jacobs <ij@w3.org>, Noah Mendelsohn <nrm@arcanedomain.com>, Philippe Le Hégaret <plh@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
On Sat, Apr 20, 2013 at 5:17 PM, Rand McRanderson <therandshow@gmail.com> wrote: > For example, the WebIDL spec has changed numerous times over the last few > years in ways that have forced spec writers to revise the WebIDL text they > are using, if someone writes a WebIDL parser they should have some way to > see that the spec whose WebIDL they are trying to parse is incompatible with > the definition of WebIDL they are using, and in what ways it is > incompatible. Yes, we do run into the problem that sometimes people are not willing to pick up specifications that need some amount of work and are effectively obsolete at this point if you try to implement them. E.g. if you want to support the browser XPath API you need http://wiki.whatwg.org/wiki/DOM_XPath to create an interoperable implementation (the old bindings did not contain sufficient detail). Nobody in the browser space really seems to care much for XPath anymore so nobody wrote a better (maintained) specification. And soon we'll have the same kind of churn with specifications that need to obtain data from a URL. They'll currently reference HTML and CORS most likely and will need to be updated to use http://fetch.spec.whatwg.org/ instead. These kind of transitions unfortunately create some amount of confusion short term, including for implementers and developers, but long term the whole platform can be more easily understood. The tooling you suggest to mitigate some of this sounds nice. I wish we had more people working on tooling around standards. -- http://annevankesteren.nl/
Received on Monday, 22 April 2013 09:53:59 UTC