XObjects (was TLAa was SOX)

[Michael Kay]

>The DomBuilder (or DOMBuilder) interface, I would argue, should not include
>a setParser method--I don't see a great deal of utility in being able to
switch
>parsers mid-stream.

The reason I had it was that two out of the three DOM implementations I have
used are built on top of SAX parsers and allow me to specify which SAX
parser to use. I guess setParser() therefore belongs in a sub-interface for
"DOM implementations built on top of SAX", but I was lazy. (It's got nothing
to do with changing parsers midstream).

>I like to think of degrees of specialization:
>
>    1.    Some applications will be based on SAX
>            and not use DOM.
>
>    2.    Some applications will be based on DOM,
>            use the DomBuilder interface, an not use
>            too much else from SAX.
>
Absolutely. One of the things I think I have achieved with SAXON is the
ability to switch easily between event-based application logic and
navigational application logic, allowing both techniques to be used in the
same application, driven either from SAX or from the DOM as appropriate,
with the same element-oriented classes for both cases. I think that is a
real requirement, because I've seen many applications that started one way
and then evolved as the processing requirements became clearer.

Mike


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)