XML API specification

[David Durand]

At 9:19 AM -0500 2/27/97, Gavin Nicol wrote:
>I think that for the *parser*, we should define an event-handling
>interface, as it is much simpler to build certain applications
>that way, and because you can build a tree from a stream of
>events if you need to.

Funny, that is exactly what I was thinking. Since reading the design
patterns book, I've become quite fond of the "Builder" pattern, where some
process like a parser takes as input an object whose methods perform
appopropriate processing as the input is recognized. It's even possible to
use Builders with things other than parsers, as long as they make the same
callbacks.

The real advantage of such an interface is that we don't impose a data
structure on an application that might not want it. For instance, many
functions are easier if you have an abstract syntax tree, but some quick
and dirty applications won't need an AST, nor will they want to take the
memory hit of building one if they don't need it...

<digresion type="Possible use of extra abstraction">

It might also be of use to define a callback interface that allows
automatic delegation of building for certain elements.

To be non-cryptic, I can see an application for a standard interface to
java applets that will automatically delegate the processing of the events
representing a particular sub-trees of the document to a particular applet.
For instance, the default Java applet interface might allow a document to
declare that <interaction-graph> elements should be processed by the class
"InteractionGraph.class" This would cause the Builder implementation to
auto-invoke the Applet for the parser events in each interaction graph, and
then would pass the Applet instance to the main application, in place of
its contents.

Think of this as (slightly goofy?) event-driven compound document renderings.
</digression>

>Some questions that will affect the API is whether one sees empty
>element as elements containing nothing, or as elements unable to
>contain anything, and wether entity/attribute type information needs
>to be passed across thr API.
>
>What do people think? How much information must the parser pass
>along?
>

All that information _must_ be available. The chief reason that I find ESIS
useless is that I can't write SGML->SGML transformations without complete
information. We should have as a goal that an identity transformation
whould be possible. By Identity, I only mean to require equivalence up to
"insignificant" whitespace normalization. I.E. We should be able to produce
an instance lacking no information that the standard does not explicitly
label insiginificant.

We should have a way for a builder to signal its controller that
information such as entity boundaries, and maybe some DTD info, is
_insignificant for that execution_.

I suppose a more-general thing would be to register the events that you are
interested in -- and others would simply be silently ignored. This could be
handled by having empty default implementations, so it may not require
special handling.

As to languages, I am sympathetic to the IDL argument, but I have a few
practical notes:

It seems that already more people know Java than IDL.
IDL information seems to cost money.

As to principles for making a decision:

* Platform independence seems a hard requirement: in favor of both Java and
IDL, against OLE/Active-X/other proprietary gunk.

* Language independence is good (but not quite a hard requirement):
This is a point in favor of IDL, but I think that many will be learning IDL
by comparing the Official Standard against the Java binding produced by the
nifty tools...

In other words, if the IDL folks can write the syntax up and post the
processed Java bindings here, we should do IDL, otherwise java is good
enough, and the inverse binding -- though inelegant -- can be created later.


   -- David

_________________________________________
David Durand              dgd at cs.bu.edu  \  david at dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



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)