Hello:
I have nearly finished the patch for XMLCatalogs loading from files. I wanted
to share with the group some of my observations and questions. My intent is to avoid
expressions of astonishment and horror as much as possible when my patch comes
in tomorrow ;-)
I carefully reviewed Norm Walsh's code in xml-commons. It is _definately_ the way
we want to go IMO. It includes a number of really nice features:
- support for the latest OASIS standard "open catalog" format, both plain text and xml varieties
- support for John Cowan's XCatalog format
- his CatalogResolver implements _both_ org.xml.sax.EntityResolver _and_ javax.xml.transform.URIResolver
The latest OASIS standard includes all sorts of advanced functionality, including
URN resolution, the ability to rewrite URIs using alternate prefixes, etc. and it is fully supported by the resolver library.
It seems to me that John Cowan's alternate XCatalog spec is not being maintained
or enhanced anymore. Consequently, the official OASIS specs have gone far beyond what XCatalog supports. While the xml-commons resolver library does include a parser for the XCatalog format, I recommend that we (longer term) aim instead for the OASIS standard. Alternatively, we could support both, but its more work.
Ultimately, we may want to support the full OASIS XML-format catalog grammar inline in
a buildfile, rather than only as an external file as I have implemented it. I stopped short of implementing the full grammar inline -- because it is alot of work,
and probably more than most ant buildfile writers need. As long as we
can load in a full-spec external OASIS catalog file, that is probably good enough, no?
I also noticed that the current XMLCatalog implementation features the ability to find resources
inside jar files in the classpath. Norm's resolver library does not include this feature,
and I think its a nice add. I am proposing to keep this code as a secondary lookup after the original lookup is done using catalog.getResolvedEntity() (using Norm Walsh's code).
************ DETAILS:
I propose the following:
1) Add a new optional file attribute to <xmlcatalog>
<xmlcatalog id="mycatalog" file="foo/bar/catalog">
<dtd publicId = "-//ArielPartners//DTD XML Article V1.0//EN"
location = "com/arielpartners/knowledgebase/dtd/article.dtd"/>
</xmlcatalog>
2) refactor DTDLocation.java, add base class, sibling
Create a base class: ResourceLocation and two derived classes DTDLocation and EntityLocation. They correspond to the "PUBLIC" and "URI" catalog entry types in the OASIS catalog spec. We need to distinguish between the two, because the resolver library calls different resolveXXX() methods based on entry type.
3) refactor resolveEntity() and add a new resolve() method in XMLCatalog.java
This is the method for the JAXP URIResolver() interface. It will call the same code currently in resolveEntity()
4) make TraXLiaison.java call setURIResolver()
If an XMLCatalog exists, call _BOTH_ setEntityResolver() and setURIResolver(), so the same catalog does double duty. kewl.
***************
What's the downside? The major one I can think of is that ant needs to now include all of the classes in the xml-commons resolver library. That means either they need to be directly included in ant.jar _or_ we need to include a separate resolver.jar with ant.
***************
OK that's (more than) enough for one email. Please let me know what you all think.
As far as I know, there are as yet no tests for XMLCatalog. Therefore, my patch will focus on the required changes to a) code b) documentation c) the ant build.xml file
Thanks very much!
--Craeg
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
