ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craeg K Strong <cstr...@arielpartners.com>
Subject status of XMLCatalog load from file patch, questions
Date Tue, 30 Apr 2002 06:42:04 GMT
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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message