[XML-SIG] SAX parser factories (Was: PyTRaX?)

[Fred L. Drake, Jr.]

Thomas B. Passin writes:
 > I favor short (non-URI) feature names.  Using URIs to get unique strings may
 > work well when you have the possibility of many people working independently
 > on many projects accidentally producing name collisions.  I don't thnk that
 > applies here.  Even if, say, the RDF people duplicated some of our feature
 > names, it wouldn't matter since they would be used in a different context.

  Why would it not apply here?  I know the "Parsed XML" product for
Zope supports some additional features that can be checked with
hasFeature(); why would this not be the case for other APIs which can
support customizable features?
  If we do go with short names, we should at least strongly recommend
a way to formulate the names for additional features.  I'd stick with
what's recommended for the DOM in this case; for example:
"org.zope.dom.persistence".

Thomas B. Passin writes:
 > I don't like make_parser() and create_parser() approach because the names
 > are so similar as to lead to confusion.  I do like the proposal to ask for a
 > list of processors that support a feature list, which ability wuld be
 > separate from actual parser creation.  I say a list because if more than one
 > had my features, I might want to choose one rather than another, not just
 > take whichever one the system wanted to give me.

  So perhaps what we have is an interface like this:

	object SAXImplementation:
            def can_set_feature(feature, enabled):
                """Return true if the parsers returned by create()
                can support 'feature', and false if they don't."""

            def can_support_property(property, value):
                """Return true if the parsers returned by create()
                can support 'property' with the given value, and
                false if they can't."""

            def get_features_list():
                """Return a list of supported feature names.
                Inclusion of a name in the list does not imply that
                the feature is supported in both enabled and disabled
                forms."""

            def get_properties_list():
                """Return a list of supported property names.
                Inclusion of a name in the list does not imply that
                all values for that property are supported."""

            def create():
                """Return a new XMLReader instance."""

        def find_parsers(features={}, properties={}):
            """Return a list of SAXImplementation objects that support
            the given features and properties."""

        def create_parser(features={}, properties={}):
            """Return a configured parser object that supports the
            given feature and property settings.  If more than one
            SAXImplementation supports the given settings, one will be
            selected arbitrarily."""

        def register_parser(impl):
            """Add the SAXImplementation 'impl' to the set of parsers
            known to the factory."""

(I expect SAXImplementation objects will usually be modules.)

 > Also, with the has_features() approach, it would be possible to keep a
 > simple features catalog which would avoid the need to instantiate a
 > processor so it could be asked if it had some feature.  If each processor
 > (or wrapper) could respond to a request for its features, a script could
 > automatically query it when it was first registered and save the data in the

  This would be fine with me.  I think the SAXImplementation interface
I outlined above would support this implementation of the factory
functions.

 > catalog.  Perhaps the catalog could be in xml, more likely a dictionary
 > format.

  I expect such a catalog would have to be a volatile data structure
rather than something persistent -- the interaction with sys.path
would be a nightmare for a persistent catalog!

 > The next step in this evolution could be named feature sets!

  That would be nice to have!


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations