xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: New resolver all checked in
Date Fri, 20 Dec 2002 06:29:14 GMT
Brian Smith wrote:
> Shane Curcuru/CAM/Lotus wrote:
> >Brian Smith wrote:
> >>(b) The resolver library does not have any special support for
> >>resolving the public ID for the DTD for XML catalogs. Thus, if
> >>you don't put that DTD in your local personal system-wide catalog,
> >>the catalog resolver will attempt to retrieve the DTD from the
> >>OASIS website. Again, it is seems very difficult to override this
> >>in a client application. Probably the resolver library should
> >>include the OASIS XML Catalog DTD inside its own JAR file and
> >>resolve this public ID specially.
> > 
> > Here I'm not so sure.  I'd defer to a larger array of cataloging
> > experts: in particular, does this DTD at OASIS change
> > ever/frequently?  If so, we 
> It is my understanding that any changes to the DTD mean that a new
> System ID and Public ID must (should) be assigned. Also, if the DTD 
> changes "silently" in any way that is semantically significant then
> the resolver library would likely no longer work with documents
> conforming to the new DTD anyway.

That sounds fair to me.

Thanks Brian, i encountered this exact issue when building
the recent xml-commons website with Forrest. Your initial
explanation came just as i was trying to figure out why the
silent failure (spooky).

Anyway, Forrest uses catalogs in two places. When building
the docs we load a default catalog using OASIS plain text
catalog and define the Catalog DTD there. Then we go on
to load other OASIS XML catalogs ... fine.

However, for the xml validation part, Forrest uses Ant and i
cannot get past this problem. So i have done the sacrilegious
thing for resolver-heads and commented-out the document type
declaration in the xml instance :-)

I like your solution.


View raw message