Simple approaches to XML implementation

[Digitome Ltd.]

[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 
>application.
>
>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
Sean Mc Grath
digitome at iol.ie
Digitome Electronic Publishing
Developers of IDM - Next Generation SGML Transformation Technology
http://www.screen.ie/digitome


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