Todd --

For the UseXMLFilters example, of course, either way will work just
fine.  The problem arises when one of the filters wants to override the
parse method.  Perhaps, it only wants to letter certain URLs through or
check some special security or something.  In your second scenario, the
parse methods of the filters never get called so there is no opportunity
to override that method in any meaningful way.  The principle with the
current design seems to be that if a filter is going to process the SAX
events resulting from a given parse, it ought to at least have a chance
to look at the parse before it gets going.

Gary

"G. Todd Miller - XML Tech Ctr - Development" wrote:
> 
> Question: In the sample program UseXMLFilters.java (located in
>  xml-xalan/java/samples/UseXMLFilters) it appears that 3 XMLFilters
>  (filter1, filter2, and filter3 in diagram) are being chained together
>  into a pipeline, a Serializer is plugged into filter3 as a
>  ContentHandler, and an XMLReader is plugged into filter1 as a parent.
>  And then, the input XML document is being feed into the *last*
>  filter in the pipeline:
> 
>   XMLReader       foo1.xsl   foo2.xsl   foo3.xsl          foo.xml
>    |   ^             |          |         |                |
>    |   |             |          |         |                |
>    |   |             v          v         v                |
>    |   |  xml   +----------+----------+-----------+  xml   |
>    |   +----<---|          |          |           |<-------+
>    |            | filter1  |  filter2 |  filter3  |
>    +----->------|          |          |           |------> Serializer
>    sax evts     +----------+----------+-----------+
> 
>  So the app program calls filter3.parse("foo.xml"); filter3 turns around
>  and calls filter2.parse("foo.xml"); filter2 turns around and calls
>  filter1.parse("foo.xml"); filter1 finally hands off the xml doc to
>  an XMLReader, the reader parses the doc and produces SAX parser
>  events. The parser events are input to filter1; transformed; output
>  of transform is sent to filter2; transformed; output to filter3
>  transformed and then output to Serializer.
> 
>  (If I am correct in this analysis) then the question: why have the
>  Xml input doc be 'forwarded' from the end of the pipe to the beginning,
>  to be read?   Why not design the pipeline such as:
> 
> 
>                  foo1.xsl   foo2.xsl   foo3.xsl
>    foo.xml           |          |         |
>       |              |          |         |
>       |              v          v         v
>       |         +----------+----------+-----------+
>       v         |          |          |           |
>   XMLReader---->| filter1  |  filter2 |  filter3  |------> Serializer
>                 |          |          |           |
>                 +----------+----------+-----------+
> 
> Thanks for any insights/corrections to this,
> 
> -Todd

Reply via email to