SAX: ModSAX addition, general property query

[David Brownell]

OK, I'll pick this thread rather than the longer one to read first...
XML-DEV really generates lots of traffic lately!!

- I agree re using URIs, like Namespaces do.  Anyone can get a URI
  nowadays, for virtually no cost, but that's not true of reversed
  domain names (as used in Java properties and package names).

- There will need to be some strong policies for how the "things"
  to which an {info,handler,feature}ID map are documented.  I think
  that leadership by example can play a strong role here ... :-)

  Related point, that policy should specify the status of the "thing".
  For example, "stable", "beta", "experimental", "private", to pick
  an order where folk should be progressively less willing to use or
  implement the "thing" in a parser.

- I'd like a "getHandler" API ... or perhaps, eliminate the notion
  of 'feature' and 'handler' IDs and just use "infoID" values that
  map to the appropriate handdlers.

  I've found it important to be able to do things like, say, "use
  the error handler everyone else is using".  (Where's getFeature?
  One can return a Boolean from a "get" ...)

Re that last point, I might have missed some e-mail and will try
to catch up.  It's not clear why there's a need for more than a
single general get/set API for this.

- Dave




David Megginson wrote:
> 
> What: Additions to ModParser interface
> 
> I'm proposing a couple of additions to the ModParser interface:
> 
>   public interface ModParser extends Parser
>   {
>     public abstract void setFeature (String featureID, boolean state)
>       throws SAXNotSupportedException;
> 
>     public abstract void setHandler (String handlerID, ModHandler handler)
>       throws SAXNotSupportedException;
> 
>     public abstract void set (String infoID, Object prop)
>       throws SAXNotSupportedException;
> 
>     public abstract Object get (String infoID)
>       throws SAXNotSupportedException;
>   }
> 
> These allow you to do interesting things like
> 
>   parser.set("http://www.foo.com/props/textfilter", filter);
> 
> or
> 
>   try {
>     Node node = parser.get("http://xml.org/sax/props/dom-node");
>   } catch (SAXNotRecognizedException e1) {
>     // doesn't know about DOM processing...
>   } catch (SAXNotSupportedException e2) {
>     // knows about DOM processing, but not doing it...
>   }
> 
> Again, it's a little sloppy as an interface, but it's beautifully
> extensible and it supports filters nicely (if there are other filters
> between the DOM iterator and the application, it will still work).
> 
> Note that strictly speaking, now, setHandler() and setFeature() are no
> longer primitives, since they could both be implemented in terms of
> set(), but I think that the extra type checking is worthwhile in those
> cases.
> 
> All the best,
> 
> David
> 
> --
> David Megginson                 david at megginson.com
>            http://www.megginson.com/
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)