- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 27 Feb 2012 21:34:43 +0100
- To: David Lee <David.Lee@marklogic.com>
- Cc: Noah Mendelsohn <nrm@arcanedomain.com>, "public-xml-er@w3.org" <public-xml-er@w3.org>
On Feb 27, 2012, at 19:17 , David Lee wrote: > If the primary purpose of defining to an API is for testability I think that makes this very hard. > Its much easier to compare and test text then API behaviour. I beg to differ :) If you're comparing text then you're already using a level of abstraction: at the very least above encodings, but since you go on to mention XML diff tools then you're thinking of comparing based on a data model. All that that does is hide the interpretation behind a tool — exposing an API makes it clear up front. I understand where you're coming from with your concern about the complexity of testing API behaviour, but this isn't really behaviour, it's just reading the output in a form that matches exactly what the parser understood. > Then test case *in Text* could be produced and tested against using the plephra of XML diff/compare tools. I think this is vastly easier than trying to test the results of say 2 DOM processors via API specs. In both cases you can produce text output, the big advantage of using a well-defined data model like the DOM is that you can describe how to produce said output text based on something concrete, rather than in mediation of an ad hoc data model. But it feels like I'm still missing something. How would you produce a serialisation if you don't have a data model? What is it a serialisation of? And if you propose to have a data model, why not use one that exists and is widely implemented? -- Robin Berjon - http://berjon.com/ - @robinberjon Coming up soon: I'm teaching a W3C online course on Mobile Web Apps http://www.w3devcampus.com/writing-great-web-applications-for-mobile/
Received on Monday, 27 February 2012 20:35:11 UTC