xml-dev - Re: Simple approaches to XML implementation

["F. Chahuneau - AIS" <fcha@Berger-Levrault.fr>]

[F. Chahuneau, 01 Mar 1997]
> >All in all, you can see that some design decisions in XML were precisely
> >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 used
the term "identity transformation" without defining it first. My implicit
definition was very minimal:  being able to generate on the output side an
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 problem
according to this definition.

As many other SGML practicioners, I've never considered the fact that CDATA
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 example
of a normalised "event-stream based" interface between a parser an
application, which could inspire more carefully designed interfaces in the
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 build
one from the other, and that this could be done inside the application. But
implementing this duality *below* the API level offers big advantages, both
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's
> 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 forthcoming
generation of XML parsers/scanners.


      _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
     _/ François CHAHUNEAU                 phone: [+33] 1 40 64 43 00  _/
    _/ Directeur Général/General Manager                              _/
   _/ AIS S.A.                             FAX: [+33] 1 40 64 43 10  _/
  _/ 15-17 rue Rémy Dumoncel    email: fcha@ais.berger-levrault.fr  _/
 _/ 75014, Paris, FRANCE        WWW: http://www.berger-levrault.fr _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

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)