SAX 2.0 extension proposals.

[Toby Speight]

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

0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A6752AB at odin.cromwellmedia.co.uk>,
0> Miles wrote:

Miles> If there aren't *any* constraints on what base implementation a
Miles> filter might be wrapped around, then it looks like the set of
Miles> features a filter+base reader combo supports would be
Miles> indeterminate.  That being the case it's hard to see how you
Miles> could select such a thing on the basis of it's features That's
Miles> not to say you can't have such a thing, just that maybe you
Miles> shouldn't expect to be able to get one out of a general purpose
Miles> factory.
Miles>
Miles> It'd be helpful if you could give me a concrete example of the
Miles> kind of scenario you're talking about ... maybe I'm missing
Miles> something.

Imagine you have 3 parsers: A, B and C; and 3 features: p, q and r.

Furthermore, suppose that A supports none of the features, B supports
p only, and C supports q only.

Now imagine we have two filters: F and G, that can be used with any of
the three parsers.  Both filters provide r; F also provides p, but
blocks q.

Summary:

Feature     p           q           r

A          no          no          no
B       provides       no          no
C          no       provides       no

F       passthru    passthru    provides
G       provides     blocks     provides


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).

That's the kind of thing I was thinking of.

-- 


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.