Re: Parameters, Manifests, and Use Case 5.6

Norman Walsh wrote:
> / 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.

I think that's an assumption about users that we haven't tested.

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

Yes, x: should map to the XInclude namespace.  I got lazy.  Smack my
fingers with a ruler! :)

I'm confused.  Where's the problem?

The {@href} expression in the XSLT transform expands to the value of the
'href' attribute.  That value is a URI which is the relative URI value 
to the document in the manifest.  The rest is done by the XInclude step.

The XInclude step does what XInclude says which is that the base URI of
the [x:]include element is used to  resolve that URI value in the 'href'
attribute.  Depending on our story about base URI values in  pipelines, 
that transform might require an explicit xml:base value to be placed on
the [x:]include element.  Otherwise, the two steps together accomplish
loading the XML document.


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

If you turn of XInclude, the pipeline fails to compile because
the pipeline *requires* XInclude.  That's just like saying if you
turn off XSLT the pipeline doesn't work.

I can't imagine how we can say you can "turn off" components used
by steps.

-- 
--Alex Milowski

"The excellence of grammar as a guide is proportional to the paucity
of the inflexions, i.e. to the degree of analysis effected by the
language considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Friday, 13 October 2006 17:09:07 UTC