W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > October 2006

Re: Parameters, Manifests, and Use Case 5.6

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 13 Oct 2006 12:17:11 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87u028nqbc.fsf@nwalsh.com>
/ 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,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC