Simple approaches to XML implementation

Digitome Ltd. digitome at
Mon Mar 3 19:32:20 GMT 1997

[Tim Bray]
>Whereas I agree with the rest of Francois' contribution, this paragraph
>is not quite right.  If you change "ESIS event stream" to "Instance
>character stream", then it would be more correct.  But in fact the
>SGML->SGML declaration was not one of our goals; for example, the 
>processor is not required to tell the app about [at least] comments
>and <![CDATA[ sections.  The XML spec says *nothing* about the ESIS, 
>merely, in a very abstract way, what the processor has to give the 
>If either of these problems (the impossibility of SGML->SGML or the
>absence of an ESIS equivalent) is a big huge flaw in XML, there's still
>time to fix it.  The SGML->SGML problem is probably a job for the
>XML WG.  The ESIS issue is perhaps a job for this list.  I personally
>think an API is better than an ESIS [even if the ESIS were properly
>defined] anyhow.

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.

Sean Mc Grath
digitome at
Digitome Electronic Publishing
Developers of IDM - Next Generation SGML Transformation Technology

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list