SAX 2.0 extension proposals.

[Toby Speight]

Miles> Miles Sabin <URL:mailto:msabin at cromwellmedia.co.uk>
David> David Megginson <URL:mailto:david at megginson.com>


0> In article
0> <AA4C152BA2F9D211B9DD0008C79F760A675291 at odin.cromwellmedia.co.uk>,
0> Miles wrote:

Miles> * A means of querying an XMLReader implementations features
Miles>   without first having to instantiate an XMLReader.


0> In article <m33drdj10x.fsf at localhost.localdomain>, ...

[David, your mail system and/or host config is broken.  Try setting
the `system-name' variable in your Emacs.  Also search the ding-list
archives for the string "localhost.localdomain" - somewhere there's a
patch that might help.]


0> In article <m33drdj10x.fsf at localhost.localdomain>, David wrote:

David> That's not too hard: it would take only a few static methods.


Without resorting to Reflection, it's not that easy.  Invoking a
static method requires either an instance, or compile-time knowledge
of the class name.  I haven't thought about the issues in a non-Java
environment.


David> There are a couple of issues, though:
David>
David> 1. For a filter (which may be more common than a root reader),
David>    the features available depend on the features supported by
David>    the parent -- in other words, you cannot know what features
David>    are supported *until* the reader is instantiated.

It would be nice if Miles gave some thought to this issue.  Perhaps
it's an insoluble problem; perhaps filters need some additional
feature types (or additional queries on those features) to indicate
how the the upstream parser's behaviour is modified.  The obvious
ones are:

1. "passthrough" - the filter provides whatever the upstream parser
   does, unchanged.

2. "override" - *EITHER* the filter supports the feature, even if the
   upstream parser doesn't *OR* the filter doesn't support the feature,
   regardless of the upstream support for it.

3. "other" - the feature's support depends on more than only the
   upstream parser's support for it; perhaps it depends also on
   another feature of the upstream parser.

David> 2. ...


Miles> * A plug'n'play XMLReader factory which supports multiple
Miles>   parsers and transparent adaptation of SAX 1 parsers.

David> Does this belong in the SAX core, or should it be a
David> higher-level app?

I second the support in this thread for maintaining SAX in two parts,
as a core and a(n| set of) extension package(s), if possible.  It
would be nice to save developers re-inventing the same wheels, and
the "SAX blessing" would help keep effort focused in one place, but
there's no need to impose the extra weight on those to whom leanness
is king.

-- 


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/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions and unsubscriptions
are  now ***CLOSED*** in preparation for list transfer to OASIS.