[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Miles Sabin <msabin@c...>
  • To: 'XML Developers' List' <xml-dev@i...>
  • Date: Fri, 21 May 1999 16:32:11 +0100

RE: SAX2: Another thought on subtyping
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@c...           England

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/ and on CD-ROM/ISBN 981-02-3594-1
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...)


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.