Re: Parameters, Manifests, and Use Case 5.6

/ Alex Milowski <> was heard to say:
| This use case is easily solved by use of xinclude:

I don't think this qualifies as "easily" in the sense that ordinary
mortals understand that word. More specifically, I don't think
you've got a complete solution yet.

| <p:pipeline>
|    <p:declare-input port="manifest" />
|    <p:declare-output port="results" sequence="yes"
|                      step="load-documents" source="result" />
|    <p:for-each name="load-documents">
|      <p:declare-input port="file-ref"
|                       source="manifest"
|                       select="/files/file" />
|      <p:declare-output port="result"
|                        step="load-document" source="result" />
|      <!-- make an xinclude from the href -->
|      <p:step name="make-xinclude" type="p:xslt">
|         <p:input name="document" step="load-documents" port="file-ref"/>
|         <p:input name="transform">
|            <xsl:transform version="1.0">
|               <xsl:template match="file">
|                  <x:include href="{@href}"/>

How have you controled when x:include (assuming you meant x: to be
assigned to the XInclude namespace) will be expanded? I'd expect the
Pipeline processor to expand it, causing a resource failure because
"{@href}" isn't a valid URI.

Assuming you load your pipeline with XInclude turned off, the same
problem arises for your XSLT processor.

                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Friday, 13 October 2006 16:17:22 UTC