xml-dev - Re: FW: SAX 2.0 extension proposals.

[Toby Speight <Toby.Speight@streapadair.freeserve.co.uk>]

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

0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A6752C5@odin.cromwellmedia.co.uk>,
0> Miles wrote:

Miles> I replied to the list, @xml.org, but I'm not sure it propagated.
Miles> Did you see it?

I didn't get it :-(
Let me know if you don't receive this.[1]

Miles> OK, so you want to be able to query for some one parser +
Miles> arbitrary filter chain combo that has all the required
Miles> features ... right?
Miles>
Miles> I'm more convinced than ever that this is application specific
Miles> logic rather than something which belongs in a general purpose
Miles> XMLReader factory. Here's why ...
Miles>
Miles> The problem is not in general soluble, because even with just
Miles> _one_ filter it'd be possible for there to be an unbounded number
Miles> of distinct filter chains (some filters might do interesting
Miles> things if applied multiple times to a single parser).

It hadn't occurred to me that a filter would be useful appearing more
than once in the chain.


Miles> So the combinatorial explosion you describe is just the tip of
Miles> the iceberg.  Resolving this problem in practice requires
Miles> filter-specific knowledge.

Perhaps my suggestion of having filter implementation classes implement
factories makes sense in this case.  A filter that simply passes through
all of the requested features ought to return "no match" of course.

I think asking all filter writers to implement this might be too much
for a core spec - if there does turn out to be demand for it, it can
be added later.


[The following quoted without comment, in case Miles's original
reached nobody]

Miles> But other than the SAX2 interface, the API is completely silent
Miles> on how filters should behave: implementations of XMLFilter are
Miles> at the application level, and it's up to the application to
Miles> determine their semantics.
Miles>
Miles> In summary: the effects of combining filters and parsers is
Miles> dependent on application level semantics, so a SAX level factory
Miles> can't be expected to handle it.

[End of quote]

Miles> On the other hand, it's quite straightforward to deal with this
Miles> at the application level, where, presumably you _do_ know what
Miles> your filters do, and how they combine.  That being so, it's
Miles> straightforward to put together 'canned' parser/filter(s) combos
Miles> and bundle them as a standalone XMLReader implementation in the
Miles> way I described earlier in this thread.

I'm not totally convinced by the first statement, but in conjunction
with the second, this covers pretty much all of what I see people
using today.

An application says, "I want a parser that provides q and r" [still
using my earlier example] and the factory says, "no can do", so the
application tries using filter F that's supplied with it (providing
r), and asks the factory for an implementation that provides q.

Or a user installs the application, which fails because it can't get q
and r together, and the user defines a pipeline CF and registers that
with the factory.  (I'm not sure *end users* will take to doing this
sort of thing though).


[1] I've CCed this, so you'll get it even if you don't IYSWIM.

--