SAX: Next Round

[Lars Marius Garshol]

* david at megginson.com
| 
|   public interface ParserFilter extends Parser
|   [...]
|   public interface Filter
|   [...]
|   public interface Filter extends DocumentHandler {

I think one of the main things we have to decide for SAX 2 is whether
to go with the middle option (separate interfaces for everything) or
whether to use subclassing/subtyping.

Separate interfaces:

 - more flexible (mix and match) and cleaner in general
 - more confusing (subtyping/inheritance provide documentation of the
 intent of the designer), also slightly risky since the number of
 possible combinations becomes very large

Sub(classing|typing):

 - we can either have the SAX 1.0 classes act as roots in an
 inheritance/subtyping tree (which is no better than the separate
 interfaces solution) or collect things into a sort of SAX2Parser
 subclass (makes future extensions difficult)

Tough call, I'd say. The separate interfaces seem better to me, and
much of the confusion can be dealt with by good documentation (which
we need anyway). The separate interfaces solution in fact reminds me
of the OOram modelling method, which is very powerful and would be
very well suited for modelling SAX. (In fact I think I'll sit down and
create a model to clear things up in my head.)

| 2. Lexical Event Handler
| ------------------------
| 
| What do we really need here?

An event to signal the end of the internal subset would be nice, in
addition to what you listed.

|   public interface LexicalParser extends Parser {
|   [...]
|   public interface LexicalProcessor {

Here we are back with the issue above.
 
| 3. Namespace Support
| --------------------
| 
|   public interface NamespaceParser extends Parser
|   [...]
|   public interface NamespaceParser

And again... :)

| Now, the best way to find out about namespace prefixes is to introduce 
| a new handler interface:
| 
|   public interface NamespaceHandler
|   {
|     public void startNamespacePrefix (String prefix, String uri)
|       throws SAXException;
|     public void endNamespacePrefix (String prefix)
|       throws SAXException;
|   }

This looks slightly bothersome to me at first sight, but maybe it's
the way to go, since the solution I think best isn't backwards
compatible anyway:

 public interface DocumentHandler {
   public void startElement(String namespaceUri, String name, 
                            AttributeList attrs);
   public void endElement(String namespaceUri, String name);
 }

However, the low-level solution you propose makes it possible to
develop a slightly non-standard parser filter with this interface.
 
Oh, and of course I still want metadata about parsers.


At some point not too far into the future, I think it would be a good
idea to identify a list of issues and then start a separate thread
about each. The discussion here is getting rather unfocused and hard
to follow.

--Lars M.


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/
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)