W3C home > Mailing lists > Public > public-microxml@w3.org > October 2012

RE: data model

From: David Lee <David.Lee@marklogic.com>
Date: Mon, 1 Oct 2012 08:54:01 -0700
To: James Clark <jjc@jclark.com>
CC: "stephengreenubl@gmail.com" <stephengreenubl@gmail.com>, John Cowan <cowan@mercury.ccil.org>, Maik Stührenberg <maik.stuehrenberg@uni-bielefeld.de>, "public-microxml@w3.org" <public-microxml@w3.org>
Message-ID: <EB42045A1F00224E93B82E949EC6675E16B0EC8487@EXCHG-BE.marklogic.com>

> 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
Phone: +1 812-482-5224
Cell:  +1 812-630-7622
Received on Monday, 1 October 2012 15:54:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:11 UTC