[
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>
Peter,
This kind of consideration is precisely what led us to define a *dual*
programming paradigm when designing the Balise SGML processing language
(http://www.balise.com).
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
possible.
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
application.
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)
|
