In the editTimesheetsXForm.xpl that you edit, I noticed you switched from using the xslt processor to using a saxon7 processor, any particular reason?
Thanks peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alessandro Vernet Sent: Thursday, October 23, 2003 10:02 PM To: OXF Users Subject: Re: different behavior with and without debugs calvin smith wrote: > The pipeline is attached. [...] Calvin, Thanks to the Timetracker WAR you sent me by private email, I was able to find the issue. As expected, it involved faulty SAX. This time the issue was not in a processor, but in a stylesheet. The first stylesheet in the editTimesheetXForm.xpl is doing: <xsl:stylesheet exclude-result-prefixes="p" version="1.0"> <xsl:template match="/root/request/request-uri"> <config> ... </config> </xsl:template> </xsl:stylesheet> So when it finds the /root/request/request-uri element, it creates your <config> as expected, but for all the other nodes in the input document that are not under /root/request/request-uri, it executes the XSLT built-in templates. And those templates output the text nodes and the value of attributes. So when running this stylesheet, the output really is <config>...</config> and then a bunch of text nodes before the endDocument(). Those text nodes after the root element is closed are of course not valid and were confusing someone down the line. The fix is simply to use match="/" instead of match="/root/request/request-uri" (there another XPath expression to modify). The updated editTimesheetXForm.xpl is attached. You might want to check that you don't have a similar problem in other XSLT files. SAX is great because it both simple and very efficient at runtime. The downside is that we have to deal with this kind of problems from time to time. I found this problem by creating a quick and dirty SAXDebuggerProcessor. When you can add it in a pipeline it works like the identity processor, but it will log all the SAX events that go through. In case you want to use it I have attached the class files. You can declare it in processors.xml with: <processor uri="oxf/processor/sax-debugger"> <class name="org.orbeon.oxf.processor.SAXDebuggerProcessor"/> </processor> And use it in a pipeline with: <p:processor uri="oxf/processor/sax-debugger"> <p:input name="data" href="#filterconfig"/> <p:output name="data" id="filterconfigX"/> </p:processor> We are thinking facility in OXF to check the SAX that flows in all the pipelines between processors, and generate an error if something incorrect is detected. Alex _______________________________________________ oxf-users mailing list [EMAIL PROTECTED] http://mail.orbeon.com/mailman/listinfo/oxf-users
