xml-dev - Re: Simple approaches to XML implementation

[Richard Light <richard@light.demon.co.uk>]

In message <199703031932.TAA20716@mail.iol.ie>, "Digitome Ltd."
<digitome@iol.ie> writes
>I am a big fan on SGML->SGML and would like to see the ESIS powerful
>enough to allow it at some level (i.e. even with certain restrictions is 
>better than not at all). I think it is important that the API - whatever
>form it finally takes - is not merely an API for *rendering XML*. What about
>all the XML processing apps that will be slurping XML prior to any
>XML publishing.
>
>Another point in favour of an ESIS rather than a function/method API is that
>the ESIS approach is automatically bi-directional. I.e. can be used to create
>XML as well as process it.

I think we need both.  Surely the API is the set of commands, switches,
etc. which the application can use to control the behaviour of the XML
processor and issue requests to it, while the "ESIS" is the well-
understood format in which the XML processor serves up the requested
results to the application?

Is it fair to say that the XML API is functionally equivalent to the
command line arguments in NSGMLS, while the "XML ESIS" is (more
obviously) equivalent to the ESIS output by NSGMLS?  That's how I tend
to see it.

The advantage of an API over an NSGMLS-style command line is that you
can have any number of bites at the cherry, retrieving relevant bits of
the XML document each time.  For example, a browsing app might start by
requesting the only element structure for the whole document (to fill an
'outline' window), then go back and ask for content for the first few
elements until it had enough to fill a 'data window'.

Richard Light
SGML and Museum Information Consultancy
richard@light.demon.co.uk
3 Midfields Walk 
Burgess Hill
West Sussex RH15 8JA
U.K.
tel. (44) 1444 232067

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)