Simple approaches to XML implementation

[F. Chahuneau - AIS]

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

As many other SGML practicioners, I've never considered the fact that CDA=
TA 
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=
e 
of a normalised "event-stream based" interface between a parser an 
application, which could inspire more carefully designed interfaces in th=
e 
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=
ld 
one from the other, and that this could be done inside the application. B=
ut 
implementing this duality *below* the API level offers big advantages, bo=
th 
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 forthcomi=
ng 
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 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 at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)