OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: SAX 2.0 extension proposals.

[ Lists Home | Date Index | Thread Index ]
  • From: Miles Sabin <msabin@cromwellmedia.co.uk>
  • To: xml-dev@xml.org
  • Date: Thu, 3 Feb 2000 15:28:18 -0000

Toby Speight wrote,
> Miles Sabin wrote,
> > You want to be able to enumerate _all_ the parser+filter
> > combinations that support "q" and "r", not just find some
> > _one_ parser+filter that fits the bill.

> That's not quite right.  The problem as I see it is that you 
> don't know which filters to try with which parsers, and so 
> you have to iterate through all the combinations until you 
> find a match.

OK, so you want to be able to query for some one parser +
arbitrary filter chain combo that has all the required
features ... right?

I'm more convinced than ever that this is application specific
logic rather than something which belongs in a general
purpose XMLReader factory. Here's why ...

The problem is not in general soluble, because even with just 
_one_ filter it'd be possible for there to be an unbounded 
number of distinct filter chains (some might filters do 
interesting things if applied multiple times to a single 
parser). So the combinatorial explosion you describe is just 
the tip of the iceberg. Resolving this problem in practice 
requires filter-specific knowledge. But other than the SAX2 
interface, the API is completely silent on how filters should 
behave: implementations of XMLFilter are at the application 
level, and it's up to the application to determine their 
semantics.

In summary: the effects of combining filters and parsers is
dependent on application level semantics, so a SAX level
factory can't be expected to handle it.

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

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS