SAX 2.0 extension proposals.

[Toby Speight]

Miles> Miles Sabin <URL:mailto:msabin at cromwellmedia.co.uk>

0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A6752AE at odin.cromwellmedia.co.uk>,
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>
Miles>   package foo;
Miles>
Miles>   public class MyFilterImpl
Miles>     implements XMLReaderImplementation
Miles>   {
Miles>     private XMLReaderImplementation
Miles>       itsBaseImpl;
Miles>
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 ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ 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.