- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 27 Feb 2012 12:51:38 -0500
- To: Robin Berjon <robin@berjon.com>
- CC: public-xml-er@w3.org
On 2/27/2012 12:31 PM, Robin Berjon wrote: > My understanding, and please tell me if I'm wrong, is that your use case > is to make it possible to have more than one API/interface based on the > same core specification. That is an important use case, yes. > If that's correct, what I'm saying is that we can build the > specification to one API, and *still* make it possible (and efficient, > useful, etc.) to have other APIs (or more broadly interfaces) layered on > top of it. And not only will it be possible, but it will be easier to > specify and test, and more conducive to alternative processors that can > interoperate properly. I understand where you're coming from. I think we'll have to agree to disagree on what's best in this case. My concern is only partly to support the use case, though that's important; it's my feeling based on experience and intuition is that it's generally best to not mix a specification for a language with a specification for a processor for that language. When you do mix that way, you tend to wind up specifying as standard many details that weren't really core to your intent for the general case. Given that you propose to document one API, would you also include rules for determining whether some other API is or isn't conforming, or would you limit the conformance terminology to processors that implement exactly that API? Thanks.
Received on Monday, 27 February 2012 17:52:07 UTC