It should work fine. I had lots of problems with xinclude in general, but after various hand-waving excersizes it boils down to this.
The first processor in the chain is responsible for parsing the XML provided by the provider to a LibXML DOM tree. It appears that most processors use a common piece of code to do this which, in 1.6.1 at least, does handle xincludes. Experimentation shows however that if a SAX processing step is first, then xincludes never do get handled. Probably this is because a DOM tree doesn't get created until the END of the SAX processing in this case, and there is no point at which text is parsed into a DOM tree directly, though I haven't delved deeply into the code for that processor. I expect a patch could be produced. It is possible that certain other processors, like maybe XPathScript, which I've not messed with, might have a similar limitation. So, the upshot is, the nature of the pipeline COULD affect xinclude processing. XSP and XSLT processors placed first should always process xincludes. On Wednesday 09 July 2003 03:03 am, S Woodside wrote: > Is this new version OK now? I was still avoiding it based on previous > comments.. > > simon > > On Tuesday, July 8, 2003, at 11:56 PM, Alex Sergeyev wrote: > > XML::LibXML 1.54 > > -- > www.simonwoodside.com -- 99% Devil, 1% Angel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
