Hey, nice picture (the first one). We should use it in our docs.
Yes, you're correct in your analysis.
> 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
Well, first of all, it's not our design, it's how a SAX2 XMLFilter works.
The reason it's designed that way, I guess: you could have an XMLFilter
type thing that contains child chains, instead of parent chains, and then
pass around the head instead of the tail, and I guess it would amount to
the same thing. When you set the ContentHandler on the head, it would pass
it to the tail. But then if you wanted to add another chain on the end, it
would have to copy data from the previous tail. The concept of having an
XMLReader/XMLFilter that "pulls" from another XMLReader/XMLFilter is
somewhat simpler, and I think more natural, even though it may at first
seem more complicated.
The primary concept of XMLFilter is that you don't want the person who
call's "parse" to know that there may be one or more transforms involved...
all they know is that they have an XMLReader. But I suppose they could
have done it the other way around. There may be other reasons why the used
the parent chaining concept instead of a child chaining concept.
-scott
"G. Todd
Miller - XML To: [EMAIL PROTECTED]
Tech Ctr - cc: (bcc: Scott Boag/CAM/Lotus)
Development" Subject: XMLFilter chaining question...
<Glenn.Miller
@Sun.COM>
06/22/2001
01:42 PM
Please
respond to
xalan-dev
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
=======================================================================
G. Todd Miller Sun Microsystems Computer Company
Software Systems Engineer 2 Network Drive, MS UBUR02-201
GE&IS XML Tech Center Burlington, MA 01803-0903
781 442-0176
781 442-1437 (fax)
[EMAIL PROTECTED]
