Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: FW: SAX 2.0 extension proposals.
 Miles> Miles Sabin <URL:mailto:msabin@c...> 0> In article 0> <AA4C152BA2F9D211B9DD0008C79F760A6752C5@o...>, 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. -- 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
