Hi, That's a useful link for background on the resolver.jar implementation of OASIS XML Catalogs - thanks for that. Xerces makes use of a full-blown XML entity-resolver which includes a URI Resolver. From what I have gathered, Woden only requires the URI Resolver, hence WODEN-14 deals specifically with this. However it makes sense not to burn any bridges for the future so it would be nice to have the option of "upgrading" to handle other XML entities should it ever be required, without rewriting the Woden URI resolver framework. This adds even more weight to your point about keeping the URI Resolver framework common.
Kind Regards, Graham. _____________________________________________ Graham C Turrell CEng, MBCS Chartered IT Practitioner WebSphere ESB Foundation Technologies DE3F16 / MP 211 IBM Labs Hursley Park Winchester, Hampshire England. SO21 2JN Tel +44-(0)1962-815018 email: [EMAIL PROTECTED] "No army can withstand the force of an idea whose time has come.". -Victor Hugo [EMAIL PROTECTED] wrote on 17/08/2006 11:03:04: > Hi Graham, I haven't checked on what Xerces does - ideally we would > have a (small) commons project across Xerces and XmlSchema and Woden > so that the URIResolver framework is common. .... goes off to check > jakarta and xml commons .... found one :-) > > http://xml.apache.org/commons/components/resolver/index.html > > Does this do the trick? > > Cheers, > Jeremy > > On 8/16/06, Graham Turrell <[EMAIL PROTECTED]> wrote: > > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> wrote on 16/08/2006 12:54:37: > > > > > On 8/15/06, Graham Turrell <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > My reason for asking is germaine to current work I'm doing on the URI > > > > resolver (WODEN-14 [1]): Sax provides a very similar resolver > > framework, > > > > and I need > > > > to either plug my resolver directly into XMLSchemaCollection > > > > > > AFAIR XmlSchema has its own resolver mechanism see: > > > org.apache.ws.commons.schema.resolver.* package. I guess the Woden > > > resolver is going to have to work with the XmlSchema resolver in order > > > to produce a fully resolved tree of WSDL and schema. Is this what > > > you're getting at? > > > > Yes you remember right. As a bit of background, > > o.a.ws.commons.schema.XMLSchemaCollection is used in (D)OMWSDLReader to > > "cache" schemas. It uses > > org.apache.ws.commons.schema.resolver.DefaultURIResolver as its default > > resolver (which basically just wraps the URI.resolve() method, virtually a > > no-op). Since we don't replace it, it is this resolver currently used in > > the Woden (D)OMWSDLReader classes. However the XMLSchemaCollection API > > allows any custom resolver to be plugged in that conforms to the > > URIResolver interface provided by that package. If we plan to use > > XMLSchemaCollection as a central part of woden parsing then it is more > > reasonable to base the WODEN-14 URIResolver framework on that interface. > > > > If we were starting from scratch, i'd want a "greenfield" resolve method > > with signature like: > > > > (1) > > public URI resolveURI(URI uri); > > (In fact this is what I currently have in my sandbox). > > > > In order to work directly with XMLSchemaCollection, a resolve method is > > needed of signature: > > > > (2) > > org.xml.sax.InputSource resolveEntity(String targetNamespace, > > String schemaLocation, > > String baseUri > > ); > > > > The differences are not vast, and the org.xml.sax package forms part of > > JAXP bundled as part of J2SE 1.4.2 and above, so clearly it is here to > > stay! > > > > Jeremy, I think in answering your follow-up question, I have answered my > > own. But I'd still like to hear any general preferences between (1) and (2) > > above (especially with regard to returning a sax object)... > > > > All comments welcome as ever! > > > > Thanks, > > > > Graham. > > > > > Cheers, > > > Jeremy > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
