SAX 2.0 extension proposals.

Toby Speight Toby.Speight at
Wed Feb 2 18:34:06 GMT 2000

Miles> Miles Sabin <URL:mailto:msabin at>

0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A6752AE at>,
0> Miles wrote:

Miles> Toby Speight wrote,
>> [snip: detailed example]
>> Now an application asks for a parser that provides q and r.  The
>> factory could use the above table to discover that C and F together
>> will provide this (no other combination works).

Miles> Hmm ... that strikes me as a tad specialized.

Me too :-)

Miles> Even so, I think the case is covered. How about,
Miles>   package foo;
Miles>   public class MyFilterImpl
Miles>     implements XMLReaderImplementation
Miles>   {
Miles>     private XMLReaderImplementation
Miles>       itsBaseImpl;
Miles>     public TableDrivenImplementation()

I assume this is a constructor, and so the name should be MyFilterImpl()?

Miles>     {
Miles>       // Search for a suitable base impl possibly using
Miles>       // XMLReaderImplementations.implementations()
Miles>       itsBaseImpl = ???
Miles>     }

This is the problem.  You would have to create as many MyFilterImpl
objects as you have parsers, and try each one.  With my example (3
parsers, 2 filters), that's only 15 different possibilities, but the
combinatorial explosion gets you pretty quickly as the number of
stacked filters increases.

My hope is that with enough information, a factory could use
elementary predicate logic to quickly narrow the field down to
the likely combinations.  (No, I'm not suggesting that *I* could
do this.  But someone might.)

Perhaps another way of going about the problem (creating parser/filter
pipelines with a given feature set) is for the filters themselves to
be factories.  Then you could ask the filter F to give you a pipeline
that supports features q and r, and knowing that it provides r, it
would simply ask the master factory for a parser that provides q.
Make the same request of filter G and it would return no matches,
since it knows it blocks q.

Does that line of thought lead anywhere?

This is all getting quite hairy (certainly it seems a bit like overkill
for core SAX at this point), and since no-one else seems interested,
I'm willing to drop it.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.

More information about the Xml-dev mailing list