Simple approaches to XML implementation

F. Chahuneau - AIS fcha at
Sun Mar 2 15:46:52 GMT 1997

[F. Chahuneau, 01 Mar 1997]
> >All in all, you can see that some design decisions in XML were precise=
> >motivated by the desire to make an ESIS event stream sufficient to 
> >implement an identity transformation, even with no access to DTD 
> >information. This is, of course, totally consistent with the idea that=
> DTDs should not be systematically needed for processing XML fragments.

[Tim Bray Sat, 01 Mar 1997]
> 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.

(Hello, Tim)
I suspect we actually agree more than it seems, but I should not have use=
the term "identity transformation" without defining it first. My implicit=
definition was very minimal:  being able to generate on the output side a=
instance which parses according to the same DTD as the instance on the 
input side. As you know, not being able to detect EMPTY elements defeats =

this purpose, whereas not knowing whether an attribute was defaulted or 
not, though it might be considered as an information loss, is not a probl=
according to this definition.

As many other SGML practicioners, I've never considered the fact that CDA=
marked sections (or comments) would not be notified to be as important in=
practice as the previous problem. (From an abtsract point of view, marked=
sections can be seen as a packing scheme allowing to deliver several 
"abstract trees" interleaved in a single file... and therefore are not 
representable on a single abstract tree. (Maybe this means I have been 
thinking in an XML-oriented framework even before it was formalized... 
which is probably why I supported the idea so readily!)

Anyway, I will not pursue (at least not here) this dicusssion which 
probably deviates from the main purpose of this list. I provided some 
precise information about ESIS because the  subject was raised, but it is=
clear that its only utility, in this discussion, is to serve as an exampl=
of a normalised "event-stream based" interface between a parser an 
application, which could inspire more carefully designed interfaces in th=
same style. A tool such as Balise, in its communication with SP, requires=
more than ESIS...

The only important message, in all what I said in my previous e-mails, is=
my conviction that a useful API should provide both event-stream *and* 
tree-manipulation paradigms. It is true, to some extent, that you can bui=
one from the other, and that this could be done inside the application. B=
implementing this duality *below* the API level offers big advantages, bo=
for maximum expressive power/flexibility ... and to avoid everybody to 
reinvent the wheel. 

[Peter Murray-Rust Sun, 02 Mar 1997 11:32:40]

> My own development depends to a significant extent on what API I can 
> use after parsing.I want it to be very clearly separated, because I 
> see a parser as being a 'bolt-in' tool rather than a component which
> drives the rest of the application. (Maybe this isn't possible, but it'=
> worth trying for).

This is indeed possible and, to my opinion, it's even required.  This is =

how Balise is implemented, both with respect to both SP (the SGML parser =

module) and to its new XML "well-formed document scanner" module. The 
parsing module should be able to operate in "slave mode", and this should=
be reflected at the API level (i.e. you need a primitive to trigger the 
parsing of an SGML document or an XML fragment). This also means you need=
the parser to be reentrant. That was not the case with sgmls, but it was =

fixed with SP, and should not be too hard a requirement for the forthcomi=
generation of XML parsers/scanners. 

     _/ Fran=E7ois CHAHUNEAU                 phone: [+33] 1 40 64 43 00  =
    _/ Directeur G=E9n=E9ral/General Manager                             =
   _/ AIS S.A.                             FAX: [+33] 1 40 64 43 10  _/
  _/ 15-17 rue R=E9my Dumoncel    email: fcha at  _/
 _/ 75014, Paris, FRANCE        WWW: _/

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