Re: Using document() with a document containing xi:includes

Hi David,

I see the issue.

I’m not that familiar with DocBook XSL, it seems to be quite a beast. If 
the template that slurps in the glossary master via document() is 
reasonably small, then you could import the whole DocBook XSL stylesheet 
from your own XSLT. Your own XSLT will override the glossary processing 
template with something that uses collection()[2] instead of 
document('…'). Then you can pass a p:pipe connection to the glossary 
XInclude step as a second document to the p:xslt’s source port.

Do you think this may be a workaround for this issue?

Gerrit


On 17/04/2018 04:16, David Cramer wrote:
> Hi Gerrit,
> 
> Thanks for the suggestion. I think I understand it now.
> 
> After I wrote that last email, I ended up working around the issue, but 
> got busy and never followed up on this thread. Now, I've hit a similar 
> situation again :-)
> 
> I just want to summarize my situation and understanding of it. I'll 
> explain the use case better this time since my example was too simple to 
> make any sense.
> 
> The DocBook xsls have an automatic glossary feature where you supply as 
> a parameter the path to a master glossary file. The xslts then use 
> document() to open that file and insert into your document's glossary 
> any terms that have been used in the document.
> 
> So we have two documents, both of which might contain xincludes:
> 
>  1. The book being processed by the DocBook xslts and
>  2. The glossary xml, which is opened by the DocBook xslts using document()
> 
> What works is to use p:load, p:xinclude, and p:store in my pipeline to 
> load the glossary and then write it out to a temp file on the file 
> system. When I use p:xslt to run DocBook xslts, I can then pass in that 
> temp file as the master glossary.
> 
> I was hoping there was a clever way to avoid writing a temp file to the 
> file system, but I can't find a way to do that.
> 
> The only way I've ever gotten document() in an xslt to provide me with 
> an file with xincludes resolved is if the file loaded by document() is 
> the also source doc for the same xslt step, but obviously there's no 
> point in doing that since that just gives me another copy of the source 
> doc.
> 
> Let me know if I've misunderstood anything. My use case doesn't seem 
> that unusual. While writing docs to temp files works, it feels like it's 
> not in the spirit of XProc.
> 
> Regards,
> 
> David
> 
> 
> 
> On 11/18/17 12:47 AM, Imsieke, Gerrit, le-tex wrote:
>> Hi David,
>>
>> In 
>> https://gist.github.com/dwcramer/6db7a8c017aae94c1ce15b15d6044642#file-load-xinclude-xpl-L32, 
>> you copy document('./loadme.xml') which is still the non-XIncluded 
>> original document from disk. As Norm explained in the message that you 
>> cited, Calabash will never instruct Saxon’s (or rather, the XML 
>> parser’s) XInclude facility to perform the XInclude.
>>
>> If you go for the p:xinclude-first approach and if you want to process 
>> the expanded document, you’ll need to change line 21 to
>>
>> <p:pipe step="xinclude" port="result"/>
>>
>> and line 32 to
>>
>> <xsl:copy-of select="."/>
>>
>> In your example, you never referred to the XInclude-expanded document
>>
>> —Gerrit
>>
>>
>> On 17/11/2017 22:37, David Cramer wrote:
>>> I was affected again by the issue cited in this tread:
>>>
>>> https://lists.w3.org/Archives/Public/xproc-dev/2013Aug/0037.html
>>>
>>> I've created a pipeline to test the approach of loading and xinclude 
>>> the document before the xslt step that uses document(). This example 
>>> assumes there's a loadme.xml that contains an xi:include:
>>>
>>> https://gist.github.com/dwcramer/6db7a8c017aae94c1ce15b15d6044642
>>>
>>> However, when I run this, the xinclude in loadme.xml is not touched 
>>> and shows up unresolved on the result port.
>>>
>>> I also tried setting xInclude="true" in a Saxon config file and 
>>> telling Calabash about it, but when Saxon tries to resolve the 
>>> xincludes, but can't seem to find the files, even if I use full 
>>> paths. Some mucking around with the parser saxon uses might get past 
>>> that, but I'd really rather have Calabash resolve my xincludes 
>>> because it supports xinclude 1.1 and the xpath xpointer scheme.
>>>
>>> I have a workaround in this instance, but thought I'd mention this in 
>>> case there's another solution or perhaps it can be addressed in a 
>>> future version of XProc.
>>>
>>> Regards,
>>>
>>> David
>>>
>>>
>>
> 

-- 
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt

Received on Tuesday, 17 April 2018 18:48:33 UTC