Re: data model

You can't test it directly, but you can devise tasks that indicate the 
correct data model must be present.  It's just like using Science to 
understand the works of God.  For example: output JSON that is supposed 
to be equivalent under some transformation rules to the XML input and 
verify that the transform is correct?  I think that is the approach 
indicated by the spec.

-Mike

On 10/01/2012 09:00 AM, David Lee wrote:
>
> I am a bit confused.
>
> How exactly does one test conformance to an abstract data model ?
>
> 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
>
> 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 ?
>
> It need never be concretely realized in the program. (its *abstract!*)
>
> 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.
>
> -----------------------------------------------------------------------------
>
> 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/>
>
> *From:* James Clark [mailto:jjc@jclark.com]
> *Sent:* Monday, October 01, 2012 4:52 AM
> *To:* stephengreenubl@gmail.com
> *Cc:* John Cowan; David Lee; Maik Stührenberg; public-microxml@w3.org
> *Subject:* Re: data model
>
> You are quite wrong about conformance.  MicroXML's data model is a big 
> help for conformance testing: it enable conformance testing to be much 
> more thorough and concrete.
>
> I also remain confident that conformance to the data model does not 
> impose any unnecessary burden on implementations.
>
> James
>
> On Mon, Oct 1, 2012 at 2:46 PM, Stephen D Green 
> <stephengreenubl@gmail.com <mailto:stephengreenubl@gmail.com>> wrote:
>
> Say I want to have a more specialised parser: Perhaps all
>
> I want is a parser to evaluate a particular XPath or small set
>
> of XPath expressions and I want a minimally sized compiled
>
> library to do my parsing just for that purpose and no more.
>
> It would be nice to have a microXPath expression language
>
> which has as few as possible ways to represent a single XPath
>
> expression. Given such a beast, I'd like to be able to create
>
> ad hoc parsers specialised to a given microXPath expression
>
> evaluation - highly optimised for performance and compiled
>
> size. I'd like microXML to allow such a parser to be conformant
>
> without it having to include unnecessary code. I'd actually
>
> prefer that conformance not even care about what the abstract
>
> data model is. Even if I want a conformant parser which can
>
> evaluate any or all possible microXPath expressions on any
>
> microXML document, I'd like that parser not to have to conform
>
> to a particular data model because that might increase the
>
> parser's cost of development, size and complexity and reduce its
>
> performance.
>
> Another possible reason to more loosely couple the abstract
>
> data from the microXML spec (which I regard as most useful
>
> in its specification of a syntax for microXMl documents) is in
>
> the matter of conformance testing. I'm not convinced (yet) that
>
> you can test conformance of the parser's abstract data model
>
> since this is likely to be invisible, internal, private rather than
>
> visible, external, public (to my comparative naivety, I admit).
>
> I'd like to see so-called 'test assertions' for microXML for
>
> conformance and interoperability testing and in producing
>
> these, I suspect, it might be found that aspects of the present
>
> spec's conformance clauses for parsers cannot be expressed
>
> as testable test assertions (or that such assertions might rely
>
> on human reading of the code base of a parser and so make
>
> fully automated testing of conformance based on such test
>
> assertions too expensive or impracticable).
>
> One suggestion I could make is to call the present spec, if
>
> the above doesn't get acceptance as enough reason to
>
> change it to any greater degree, something like microXML
>
> - Xyz Data Model specification (where Xyz might be 'Tree'
>
> or 'Hierarchical' or even 'Compound' or just something
>
> like 'Level 1'). This would 1) indicate that there might follow
>
> some specs for other data models - and leave room for such
>
> and 2) mean that a conforming parser need only claim
>
> conformance to this particular data model. Better, I think,
>
> might be to add to the conformance section either a
>
> placeholder note or a conformance clause to cater for more
>
> specialised microXML parsers (such as my description above
>
> of a parser optimised for evaluating general or specific XPath
>
> expressions on a microXML document).
>
> ----
>
> Stephen D Green
>
>
>
> On 28 September 2012 16:49, John Cowan <cowan@mercury.ccil.org 
> <mailto:cowan@mercury.ccil.org>> wrote:
>
> Stephen D Green scripsit:
>
>
> > Haven't there already been several different abstract data models
> > put foward for XML?
>
> Yes, but XML is a complex standard and there are lots of things which 
> might
> be of interest.  The XML Infoset is an attempt to give standard names to
> some of those things, though there are plenty more which are left out.
> The PSVI could be used to report DTD information, but nobody does.
>
> MicroXML is so trivial that it's not very interesting to provide 
> alternative
> data models.  You could, for example, leave out attributes, but it's 
> simpler
> just to ignore them if you don't care about them.  Similarly, you 
> could report
> on lexical minutiae, but there are only a few: single vs. double quotes
> and whether character references are used are the only ones I can 
> think of.
>
>
> > Can't we have parsers for MicroXML which support a variety of data
> > models?
>
> In principle, I suppose, but to what purpose?  MicroLark supports push
> parsing (SAX-style), pull parsing (StAX-style), and tree building, but
> only one data model, namely that there is one element object for each
> element in the document, and it contains a name (a string), an attribute
> map from names to strings, and a sequence of children which are either
> strings or element objects, all of which must be reported.
>
>
> > I also came across mention of 'compounds' as an alternative
> > abstract data model for XML - may a parser not implement such if
> > it wants to claim to be conformant?
>
> The MicroXML data model is a simple subset of the compound model.
> To represent MicroXML in the obvious way, you'd have two kinds of
> compounds, element compounds and textual compounds.  An element compound
> has a STRING representing the element name, a TAG marking it as meta,
> a DIRECTORY mapping attribute values (textual compounds) to attribute
> values (also textual compounds), a KEY SET containing all the keys in the
> DIRECTORY, and a LIST consisting of the children.  A textual compound
> has a STRING representing the text, a TAG marking it as a text string,
> and an empty DIRECTORY, KEY SET, and LIST.  So a parser reporting these
> compounds would fully instantiate the MicroXML data model.
>
> <http://www.cl.cam.ac.uk/research/security/dendros/compounds-poster.pdf>
> gives a brief explanation of these terms.
>
> --
> John Cowan cowan@ccil.org <mailto:cowan@ccil.org> 
> http://www.ccil.org/~cowan <http://www.ccil.org/%7Ecowan>
> Dievas dave dantis; Dievas duos duonos          --Lithuanian proverb
> Deus dedit dentes; deus dabit panem             --Latin version thereof
> Deity donated dentition;
>   deity'll donate doughnuts                     --English version by 
> Muke Tever
> God gave gums; God'll give granary              --Version by Mat McVeagh
>