>So perhaps it would be useful to create filters that
>only do the conversion from XNI to DOM trees or SAX
>events. Then the parser classes would use these classes.
>This would make it easier for people to build DOM trees,
>for example, from XNI streams without carrying along
>any of the extra baggage that is part of the DOMParser
>class.


One very strong vote in favor. This would also presumably make it easier to plug in other "translating" output stages, such as my XNI to DTM builder.... or to set up Elena's revalidating pipeline.

XNI's about data flow from component to component. It should be possible to treat an XNI-to-whatever stage as just another component. Once the pipeline is assembled into a configuration it should be controllable at the pipeline (configuration) level. And for basic reasons of software architecture hierarchy, it ought to be possible to treat configurations themselves as components.

______________________________________
Joe Kesselman / IBM Research

Reply via email to