Lists Home |
Date Index |
- From: Toby Speight <Toby.Speight@streapadair.freeserve.co.uk>
- To: "XML developers' list" <email@example.com>, Miles Sabin <firstname.lastname@example.org>
- Date: 03 Feb 2000 18:09:44 +0000
Miles> Miles Sabin <URL:mailto:email@example.com>
0> In article
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.
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> 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> 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
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> 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
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).
 I've CCed this, so you'll get it even if you don't IYSWIM.