Lark 0.90 available, with an applica

Tim Bray tbray at
Fri Jun 27 23:42:01 BST 1997

At 02:08 PM 27/06/97 +0000, akirkpatrick at wrote:
>I did something very similar recently (admittedly in C++)
>and abandoned it...
>1. Leads to "class spaghetti" with similar code being spread
>all over the place.

In the XtoH application, the ElementLogic class from which all the 
element classes are subclassed has an atStart(), an atEnd(), and
a doText().  In a lot of cases, the atStart/atEnd amounted to "emit the
following string, interpolating the following attribute values".  So
yes, a lot of parallelism, but this seemed a fair price to pay for
the independence and modularity.

>2. There is usually a large degree of dependence between the
>elements and the driving application. Often the elements need
>to access the driving application directly and there is no obvious
>and efficient way provide this interface.

Not always true.  I don't do C++, but in Java, after the controller
cooks up the per-element object, he calls its method 
registerController(this) - the per-element classes all have
a mController member, thus they can callback to the controller.
The amount they had to do so was pretty small.

>3. You need to create a new class for each new element type
>(less of a problem in Java?). For C++, this means recompiling
>the application.

Non-problem in Java... in fact, you don't even need to know what
you've got when you start; when you find a new element, you can
dynamically see if there's a class for it.

>I'd be really interested to hear views in favour of the class approach.

Why I wrote this.  I would say that while we'd all prefer a declarative
stylesheet approach, it is my belief that in a lot of cases it's going
to be common to use, at least occasionally, some per-element custom
logic.  Java makes this easy enough to be very appealing as a general

 - Tim

xml-dev: A list for W3C XML Developers
Archived as:
To unsubscribe, send to majordomo at the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at

More information about the Xml-dev mailing list