Next Round

[david at megginson.com]

Bill la Forge writes:

 > Namespace Support
 > --------------------
 > 
 > Why not support Namespaces through a filter? Why put everything
 > into a monilithic parser?  If we have good support for filters,
 > then we can have a reasonable scope for parsers and allow
 > applications to configure their filters to meet their particular
 > needs.

I think that there is a reasonable probability that many parsers will
already be handling namespace processing internally, so it would be
more efficient to be able to take advantage of their work rather than
duplicating it in an external filter.

 > Filter Interface
 > -------------------
 > 
 > We are looking at building trees of event filters in MDSAX, with
 > event processing dependent on document type, element type, and
 > other application-specific considerations. An api which constrains
 > filters to a simple sequence doesn't really get us where we want to
 > go.

All you need is one standard broadcast filter and you're set -- think
of tee-joints in a pipeline.

 > And if LexicalProcessor extends DocumentHandler, then Filter should
 > extend LexicalProcessor. This would really be ideal!

I'm a little nervous, though, about pouring concrete over our design
like this -- I'd like to keep it a little more modular, especially
with schemas still far from being resolved.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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)