[
Lists Home |
Date Index |
Thread Index
]
- From: Miles Sabin <msabin@cromwellmedia.co.uk>
- To: 'XML Developers' List' <xml-dev@ic.ac.uk>
- Date: Fri, 21 May 1999 16:32:11 +0100
David Megginson wrote,
> I was thinking about this problem last night, and it
> occurred to me that the ability to query and set
> features and properties might be useful not only for
> parsers but also for handlers, and perhaps for
> specialised data structures of some sort. If that's
> the case, then a separate interface makes a lot of
> sense
<snip/>
That'd be quite a nice why of making what would've been
a wart into a feature.
Unfortunately I'm not sure that there really is anything
that can be usefully done with the Configurable
interface on anything other than Parser. Who would use
it? Not a Parser surely: a general purpose parser can't
be expected to do anything very much with any special
features of the innumerable client-side handlers that
might be plugged into it. The client itself? Well, if
the client needs to support extended functionality on
its handlers it should just define a clean, strongly-
typed extended interface and use that directly. To do
otherwise would be poor software design practise.
In part the reason for this contrast (between Parser and
the other interfaces) is that parsers represent a
relatively tightly constrained domain: that means
there's a reasonable prospect of providing access to
their functionality via a reasonably simple, well
defined interface, and being able to reuse them via that
interface. SAX1 has done that up to now, but it's become
clear over time both that some extensions are necessary
for some applications, and that those are not
necessarily desirable in all parsers. That, to my mind,
is enough to motivate David's extensibility mechanism
for SAX2.
Handlers, on the other hand, don't represent anything
like so tightly constrained a domain: they represent
what an application _wants_to_do_with_ a parser, and
there's no way we can set bounds on that. This being so,
we shouldn't expect handlers to be particularly
reusable, and so the pressure to find an extensiblity
mechanism for them is considerably less than it is for
parsers.
Cheers,
Miles
--
Miles Sabin Cromwell Media
Internet Systems Architect 5/6 Glenthorne Mews
+44 (0)181 410 2230 London, W6 0LJ
msabin@cromwellmedia.co.uk England
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|