Re: Parameters, Manifests, and Use Case 5.6

/ Alex Milowski <alex@milowski.org> 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,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.