Hi again,
Further researches into my problem have been revealing.
The logs do indeed reveal Saxon 8.3 is having trouble with document():
net.sf.saxon.trans.DynamicError: java.io.FileNotFoundException: C:\bin\cocoon-2.1.7\westminster-c.svg (The system cannot find the file specified)
... it's looking in the wrong place, as the correct file would be at C:\bin\cocoon-2.1.7\build\webapp\Briarpatch\westminster-c.svg
Is this a problem whose only resolution is on the Saxon side?
Alternatively, maybe I can pass a magic parameter into the transform to provide the missing bit of the path.
On another front, I have now managed to get document() working under Xalan, but get an error from XSLTC. I guess document() is inoperable there for its own particular reasons? (I guess it makes sense.)
Given this, I have thought about handing the information I need into the transform by aggregating it into the source. But I am reluctant to give every source file the extra baggage of the entire list of images on the chance it might need one or two of them.
In order of preference, I guess my options are: * find a solution or setting for Saxon so it "just works" * pass some parameter in to amend path so Saxon does not traverse from Cocoon's root * provide documents with a mini-directory listing possible images with their dimensions
I'm sure this kind of thing has been dealt with before. Another solution for me would be to force the user to maintain the catalog. But that's no fun at all.
Is anyone tracking this on the Saxon list? ;->
Gratefully, Wendell
At 03:18 AM 4/9/2005, you wrote:
Wendell Piez wrote:Yes. Further research has suggested that problems with it in the past should have nothing to do with this case. The FAQ warns against document() and offers intelligible reasons for avoiding it, but apparently it is supposed to work.
Well, in the 2.0.x series and early 2.1.x releases changes in content pulled in via document() indeed didn't cause invalidation of the cached pipeline result. Touch one of the sources of the generators in the pipeline, or the stylesheet itself in order to reset the cache and see whether it helps.
In my experience, Saxon 7.3 also had the habit of logging NPEs from its EntityResolver and occasionally causing failures when using document() in Cocoon 2.1.5. I was not able to reproduce the problem consistently, and ultimately switched to pipeline aggregation and XInclude.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
====================================================================== Wendell Piez mailto:[EMAIL PROTECTED] Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
