Re: data model

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> 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   http://www.ccil.org/~cowan
> 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
>