> >- Changing resolveEntity everywhere to take a name and baseURI parameter > >- Calling the appropriate resolver (via getEntityResolverVersion and > >static_cast) > > The appropriate resolver should be invoked by looking at the > use-entity-resolver2 feature (that the user could decide to turn off even > if she provides an EntityResolver2 interface) > The spec seems to imply that this flag should be set if the implementation supports ER2, and that the client can use this feature to determine if it is supported. Since if you want ER1 behaviour, you just pass an ER1 class to setEntityResolver, it would seem unnecessary to support passing in an ER2 object and turning off the feature that allows it to be used. I can't really see a situation where you would want ER1 behaviour, but with an ER2 object -- you are most likely to want it if it is present, otherwise you'd just use an ER1 object instead. I don't see that the spec allows you to turn this feature off explicitly, but if all the other features are RW then I suppose that would make sense by extension.
If it really is necessary to support that, then it still comes back to each of the many places that have an ER1 resolver installed (via the SAX parser) having either a further pointer, or a flag, to an ER2 interface. (Alternatively, they need to be able to get back to the SAX parser that created them, and then query for the feature, which is beginning to sound pretty revolting...) > It looks like the specs don't take into consideration XML Schema; what > should "name" contain in that case? I have no idea! > If this resolver should be invoked only when a DTD entity is being > resolver, the informations is almost there; the LastExtEntityInfo > structure > needs to be extended with a "name" field, that getLastExtEntityInfo would > fill by using the XMLEntityDecl currently in scope. > Right, I can have a go at that. > >Then I'm also left with the getExternalSubset() function, which again, I > >don't know where or how to implement. > > It should probably be handled like the setExternalSchemaLocation is > handled; when isRoot is true and the setting has been set, the > resolver is > invoked and the DTD is parsed like it was specified in the prolog. > I'm not entirely clear about that, but I'll have another look around the code and see if it makes any more sense. Thanks, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
