Re: data model

On Mon, Oct 1, 2012 at 7:00 AM, David Lee <David.Lee@marklogic.com> wrote:

> I am a bit confused.****
>
> How exactly does one test conformance to an abstract data model ?
>

By providing a non-normative, concrete representation of that abstract data
model, as we've done in MicroXML.  It doesn't have to be normative in the
MicroXML spec, but it can be normative for a separate test suite.  This is
a very well trodden approach in many such cases.



> ****
>
> I do  believe that having one is critical for design but how does one test
> it ?
> Take Steven's example ... and simplify it more say I write an "uxgrep"
> tool that takes****
>
> ** **
>
> Input: List of files containing Text serialized Micro XML
>

Just as a side note "Text serialized" is redundant.  Sounds like you're
just describing MicroXML.  That's not just to be nit-picky.  I want to be
sure it's clear that the only standard and concrete form of MicroXML qua
MicroXML is the syntax.



> ****
>
> Output: Plain text names of all files which have content which matches the
> expressions.****
>
> ** **
>
> ( fyi this would be similar to the xml command "xgrep") ****
>
> ** **
>
> Now ... how does one validate that the correct abstract data model is in
> fact used ?
>

That's up to the developer.  I could think of many ways, including the
super-simple step of adopting the non-normative representation of the data
model just for purposes of unit testing the components of interest within
the tool.



> ****
>
> It need never be concretely realized in the program. (its *abstract!*)
>

Abstract is relative, if you really think about it.  It's Turing machines
all the way down (IIRC even quantum computing doesn't break that
fundamental model), so you should always have *something* you can represent
into testable form, if you wish to.



> ****
>
> That doesn't mean the model isn't there ... its in the aether of the
> program design.****
>
> Similar to say how protocol layers can sometimes be merged in
> implementations ... doesn't mean they don't exist.   ****
>
> ** **
>
> So I don't see how one actually tests conformance with an abstract data
> model ... ****
>
> In this case one only could test if the whole black box worked  'as if'
> the model were accurately represented.   There might be parts of the data
> model one chooses to ignore, say if you had uxpath which didn't handle
> attributes.   Thats a perfectly valid tool but impossible, and unnecessary,
> to test if attributes were correctly preserved in the abstract model.****
>
> ** **
>
> I personally think that is sufficient ... but does imply that wording for
> conformance testing need be particularly vague.   And it doesn't imply the
> abstract data model has no value or is too constraining.   It simply may
> not always be 100% testable.
>

James did not claim it's 100% testable.  I certainly say no such thing
because I don't think it's a claim that anyone needs to make.  James did
say "MicroXML's data model is a big help for conformance testing."  Very
big difference there.


-- 
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji