Re: ixml terminology.

>> Attached, markdown. As per my action todays meeting.
>> Please tell me if (where and how) it is in error.

I think Michael’s second diagram, with two levels, is closer to what I
was thinking about in the meeting.

I think it’s important to keep in mind that implementors and users are
going to have quite different views. I don’t think the user view is all
that difficult to explain:

You hand your processor an ixml grammar (in whatever form(s) your
processor supports) and an input (a sequence of characters). It returns
a data model. The conformant option is to return an XML data model, but
it might be able to return others. “Returns” might mean hand me an XDM
or it might mean hand me a serialized string or it might mean scribble
the serialized string onto disk.

For implementors, it’s a little more recursive. In principle, I start
with the ixml grammar for ixml and I somehow use that to build a parser
that will parse ixml grammars. (I bootstrapped the process by writing
some code to read the XML format of the ixml grammar and build a parser
from that.) Having used an ixml grammar to make a parser for ixml, I
take the ixml the user gave me and I interpret that with the parser for
ixml that I generated from the XML format of the ixml grammar and I use
that to build a parser for the users grammar. I interpret their input
with that grammar and I get a (set of) parse trees. I serialize one of
those.

I don’t actually think we need to describe this process in great detail
anywhere. But it’s sometimes a little disorienting to work on. “Right,
I’m at the breakpoint I added to the Ixml.getGrammar() method, but am I
building the parser for ixml, or am I building the parser for the user’s
grammar? Where am I going and why am I in this basket?”

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica