OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Fw: Trees versus event streams

[ Lists Home | Date Index | Thread Index ]
  • From: "F. Chahuneau - General Manager" <fcha@Berger-Levrault.fr>
  • To: xml-dev@ic.ac.uk
  • Date: Sat, 1 Mar 1997 12:09:01 +0100 (MET)

[Peter Murray-Rust (Peter@ursus.demon.co.uk), Thu, 27 Feb 1997]

> My current problem may highlight this. A CML document is highly
> tree-structured and contains no mixed content, so that eventStreams don't
> contribute much. BUT it also includes chunks of HTML where a tree
> structure is quite inappropriate. If I take a Lark-based approach (or my
> own parser) the HTML gets rendered into a tree. I am now hacking this
> back into an event stream to render the hypertext. Not only does it
> take more effort, but I'm sure that holding HTML as a tree has a
> memory hit. Ideally when I'm parsing CML, and come to the
> tag <XHTML> (sic) which contains <BODY>, I'd like to tell the parser
> 'stop parsing as a tree and just hold a hypertext string until </XHTML>


This kind of consideration is precisely what led us to define a *dual*
programming paradigm when designing the Balise SGML processing language

Being able to switch back-and-forth between these two useful and
complementary abstractions for an SGML document (a "tree of typed nodes
with attributes" vs an "ESIS or ESIS+ event stream") is, from our
experience, often required when you have to express complex processing
tasks on SGML documents, but still want to keep your code as concise as

No paradigm is inherently better than the other: it all depends what you 
want to express. If you want your code to remain legible and maintainable
(i.e related in a straightforward way to the processing idea it expresses),
then you really need both in some cases. If you are interested, this idea
is further developed in the following paper: "Event Driven or Tree
Manipulation Approaches to SGML Transformation" presented at SGML'96 and 
available at "http://www.balise.com/current/articles/lecluse.htm"

> We *could* do this with a PI, but would have to all agree.

Doing this with a PI does not seem to be the best idea, since it does not
leave a choice to the application programmer which mode she wants to use 
for what, while the best choice may entirely depend on  what she wants to
do. Being able to switch betwwen tree an event-stream mode on any GI event
is what is required. For maximum generality, you also need to be able to 
generate an event stream during (sub-)tree traversal, maybe not the
*original* tree, but one which you have modified or created through your 

In the world of traditional SGML applications, sheer document size is
frequently an issue, so that tree mode must often be used with parsimony.
In the case of XML or HTML fragments, this problem is probably negligible.
The rationale for maintaining an "event stream" paradigm in an XML API is,
therefore, not to save memory, but simply that it might the most
appropriate in some cases.

       _/ 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)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS