Hi everyone,
We've been re-evaluating our original
approach for including support for XML catalogs. Instead of adding a new
parser property we think it would be better to use the existing entity
resolver property and make what would have been a catalog manager an implementation
of XNI's XMLEntityResolver which would probably live in the util package.
We would provide an implementation of resolveEntity but users could
override it to do something else. They could also use the source
of the class we provide as a template for creating catalog resolvers for
other types of catalogs. Having disjoint resolvers forces that we
come up with an order for calling them (with no spec to base on which to
base a decision) which we originally did but we're now aware of several
use cases where consulting the catalog and then calling an entity resolver
isn't the appropriate thing to do. Having that behaviour built into
the parser would work for some but certainly not everyone, and since what
we were discussing looked very much like an entity resolver anyway, why
call it something else?
I propose we just have a utility class
(for now) as well as including the XML commons resolver with the parser.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@xxxxxxxxxx
E-mail: mrglavas@xxxxxxxxxx
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
|