Support #6385
closed
Saxon fails if catalog file does not exist
Fixed in Maintenance Release:
Description
Saxon fails if a XML catalog file given by commend line option -catalog does not exist:
"%JAVA.EXE%" ^
-cp "%SAXON.CLASSPATH%" ^
net.sf.saxon.Transform ^
-xsl:"%XSL.INPUTFILE%" ^
-s:"%XML.INPUTFILE%" ^
-o:"%XML.OUTPUTFILE%" ^
-catalog:catalog.xml
results in
Transformation failed: Catalog file not found: catalog.xml
XML Catalogs V1.1 spec says
8. Resource Failures
The catalog processor is sometimes required to load a catalog entry file. This may occur at the beginning of processing, when dealing with the initial list of catalog entry files, or during subsequent processing of a nextCatalog entry or one of the delegate entries.
If the processor attempts to load a resource and fails (because the resource does not exist or is not reachable, for example), it must recover by ignoring the catalog entry file that failed and proceeding.
Am I missing something?
Files
- Category set to Resolvers
- Assignee set to Norm Tovey-Walsh
The design feels right to me despite any disagreement with the standard. Is there any reason to ignore the error other than that's what the standard says a processor should do?
It's always challenging for a specification to attempt to describe implementation behavior. In this case, I think we have to read the XML Catalogs specification as describing what an XML Catalog processor must do.
But Saxon is not, itself, an XML Catalog processor. It has access to one that it uses during resource resolution. That catalog processor does, as required, ignore resource errors.
I don't think it's non-conformant for Saxon to inspect the arguments that it's given and report an error if the catalog file doesn't exist. This is taking place long before the catalog resolver is actually used to resolve a resource.
Some users will be attempting to use a catalog and will appreciate being told that the catalog they specified doesn't exist. Other users will be passing the catalog argument so that it will be used if it exists, but they don't care if it doesn't exist.
On balance, I think I agree with Mike that warning users a file doesn't exist in this case is probably the behavior that leads to fewer surprises for users.
- Tracker changed from Bug to Support
- Status changed from New to Closed
We decided to close this with no action. I agree with Norm's reasoning here: while a catalog resolver is required to recover from this failure, an application that invokes a catalog resolver is entitled to verify that the requested catalog exists before passing it along.
Please register to edit this issue
Also available in: Atom
PDF
.