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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: ModSAX (SAX 1.1) Proposal

[ Lists Home | Date Index | Thread Index ]
  • From: "Ingargiola, Tito" <ti64877@imcnam.sbi.com>
  • To: "'xml-dev@ic.ac.uk'" <xml-dev@ic.ac.uk>
  • Date: Wed, 17 Feb 1999 10:24:09 -0500


	Why is interface ModHandler empty?  Presumably, (an implementation
of) ModParser is going to need to call methods on its handlers as it goes
about its business .  Will it somehow know that for ModHandlers which
implement, say, namespace processing, that it should call a particular
method (I won't even attempt to suggest what that method might be :-)?

	In java, empty "marker" interfaces appear:
		1) for pieces of "silent" functionality like Cloneable and
Serializable where a standard interface simply doesn't apply, or 
		2) where the variety of types of applications which will
need to have a formalized contract with some piece of functionality is so
broad that it is prohibitvely difficult to define the appropriate method
signatures for that interface; extended interfaces are expected to
proliferate (e.g., EventListener & friends).

	It seems to me that SAX is clearly not a case of 1), and while it
may be a 2), it isn't obviously so.  EventListener is nice in the regard
that it makes explicit that "there exists a contract between things that
propagate events and things that respond to them"; it doesn't fix that
contract for us, but it sets the tone of interaction.  "EventSources" of
essentially any kind are provided a template of how to interact in a
decoupled way with those interested in what they're up to.  In the case of
SAX, the "EventSource" doesn't vary all that much; in some form or another
we're always dealing with an XML parser.  Do we need such latitude in
defining the interactions between the parser and external modules?  

	I'm afraid that ModHandler's current (suggested) definition is too
open-ended -- it may encourage interoperability problems.  The key virtue
(in my opinion) of SAX is that it allows me to plug an arbitrary parser into
the front of my XML processor and I'm nearly guaranteed that if it's IBM's
or J. Clark's or whomever's, it's going to work.  A marker interface inside
the parser seems to me to threaten this happy state of affairs...  



	ps - I also "vote" with D. Park that "ModularParser/Handler" are
nicer names than "ModParser/Handler"... otherwise developers may be confused
that ModParsers are just Parsers that like vespas, bomber jackets and The
Smiths... ;->

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