Cart
[Home] [By Thread] [By Date] [Recent Entries]
John Cowan writes:
> David Megginson scripsit:
>
> > I'd like to lose EntityResolver and DTDHandler (who uses them?),
> > but I don't know if we can.
>
> Nope, nope, nope. In particular, I still have a project to finish
> a standard EntityResolver that understands Socats. By having such
> a thing, you can fit Socat support into arbitrary applications
> using arbitrary SAX parsers. Keep it. As for DTDHandler, it
> exposes stuff that XML 1.0 requires a parser to expose.
Yes, yes, yes, I know -- I've made the same argument before in many
places.
In retrospect, I think that unparsed entities and notations were a
mistake for XML (there are less opaque and more web-friendly ways to
accomplish the same thing), but they're there in the REC and, as you
say, the spec is quite explicit about reporting requirements. I was
just fantasising out loud...
> > 1. Filter Interface
>
> I propose a fourth alternative: provide ParserFilter as a helper
> class, and don't have a separate interface. Parser filters are
> just parsers that have a "parser(Parser)" constructor.
Yes, but what interface should the helper class implement? Will have
have a hard-coded level-two parser interface that knows about
namespace and lexical handlers? What if we add another standard
capability in the future?
The advantage of a separate interface is that it's easy to mix and
match; the disadvantage of a separate interface is also that it's easy
to mix and match.
> One particularly nice feature of this is that it is the pattern
> used by Java {Input,Output}Streams and Readers/Writers: Chain of
> Responsibility.
I agree -- chain of responsibility is a great benefit of the filter
approach, however we manage it.
All the best,
David
--
David Megginson david@m...
http://www.megginson.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
