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

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
>>
>>
>