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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: SAX2: Another thought on subtyping, modification, etc.

[ 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

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



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)


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

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