> James You write a program using your parser's API that serializes the abstract data model in some format (such as the JSON format described in the spec). Then you feed this program your test cases and check that for each test case the output is a representation of the correct abstract data model. This only works if you in fact are using a layered parser with an API. I can certainly imagine Micro XML *processors* that do no such thing ... do not actually represent the full abstract data model, yet I would still call conformant. Imagine this simple practical case. A Micro XML processor that counts the number of tags. It need not be built upon a fully featured parser. Yet it should be considered "conformant" if it produces the right answer for any MicroXML document. And "right" can be unambiguously defined given the parsing rules and abstract data model. I am happy as long as we don't make a statement that says all conformant processers must have a component to validate that the abstract data model is actually used. But OTOH having an abstract data model is critical to test these processors otherwise how could one say what the answer would be ? So I think we are good on both fronts. Specifying an abstract data model, indicating that it is valuable for conformance testing, but NOT saying that every conformant processor needs to expose the data model. (please don't fall into the DOM trap of defining an actual interface !) ----------------------------------------------------------------------------- David Lee Lead Engineer MarkLogic Corporation dlee@marklogic.com Phone: +1 812-482-5224 Cell: +1 812-630-7622 www.marklogic.com<http://www.marklogic.com/>
Received on Monday, 1 October 2012 15:54:40 UTC