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: David Megginson <david@megginson.com>
  • To: "Ingargiola, Tito" <ti64877@imcnam.sbi.com>
  • Date: Wed, 17 Feb 1999 12:30:13 -0500 (EST)

Ingargiola, Tito writes:

 > Thank you for your response and the example you provided.  The
 > rationale you provide for having a marker interface is good in that
 > it provides full generality -- *any* kind of handler can be
 > attached to the parser to do *any* kind of thing.  Ok.  

 > My feeling is that while there may be a slew of PingHandler -like
 > handlers which will do who-knows-what, there will also be a (more
 > common and useful!) set of *Handlers which will do the same kind of
 > things; it would be unfortunate if handlers which did the same work
 > (e.g., validation) had different interfaces simply because no
 > structure was provided for the implementors to follow.

Actually, I wasn't planning on including a validation handler at all
-- I'm not even certain what such a thing would do except receive
error reports, and that's already covered in the SAX 1.0 ErrorHandler
interface.  In my design, validation would simply be a feature to be
turned on and off; however, if someone else thought up a better
approach, they would be free to implement it.

 > I see two ways around this difficulty.  The first is to define a
 > set of subinterfaces of ModHandler which are adapted for particular
 > uses.

I expect there to be a 1:1 mapping between handler IDs and handler
interfaces.  For example, "http://xml.org/sax/handlers/namespaces"
would always require an object that implements the
org.xml.sax.handler.NamespaceHandler interface.  I do plan to include
a few basic interfaces (LexicalHandler, NamespaceHandler, etc.), but
their use will entirely optional.

To this extent, then, it looks like we agree.

 > Another means to the same end is to have a mechanism by which a
 > parser can lookup (perhaps using the URI mechanism you and
 > D. Brickley have been discussing) specific types of *ModHandlers.
 > Thus a parser can learn about a particular kind of handler on the
 > fly.  

 [ and then, on the disadvantages]

 > at least looking at CORBA's Dynamic Invocation mechanism as an
 > example, tends to be overly complex and messy.

Agreed -- it has to be simple.  Furthermore, we get into very some
nasty security problems with this sort of thing, and it's hard to port 
across languages.

I'd use URIs only as unique identifiers, not with the expectation of
being able to grab a resource using them.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

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