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

[Thomas B. Passin]

I was thinking of something like this (ignoring any distinction between
properties and features):

def get_processor_list(featurelist):
    '''Return a list of parsers (by name or registered ID, these would not
be instances)
    that support the requested features.  Each item of the
    list can be instantiated by a call to create_named_parser().'''

def create_named_processor(parsername, featurelist):
    '''Instantiate a parser using a parser name as returned by
get_parser_list.'''

These would be in addition to Fred's suggestions (copied below), except that
neither of these methods should belong to a specific processor
implementation (since they look across all of them). I'm not yet quite clear
on what class they should be part of.   With this approach, you can take the
first processor on the list if you don't care which one you use:

processors=get_processor_list(featurelist)
if processors:
    parser=create_named_processor(processors[0],featurelist)
else:
   bye_bye_right_now()

Or if you know you a particular one, use it by name if it shows up in the
list.  This api should work nicely for other types of processors in the
future, so it would give us a uniform approach to wrapping processors that
may have various features.

Cheers,

Tom P

Fred L. Drake wrote -
>
>
>   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
>
>