Re: The first five minutes ... a thought experiment (long)

On Wed, Feb 19, 2014 at 2:48 AM,  <pmenso57@comcast.net> wrote:

>
> To be clear, I have not run into issues with the way that it is now.  The default piping itself is what actually gives me pause from time to time.  For example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0" xpath-version="2.0">
>     <p:serialization port="result"
>         version="1.0" omit-xml-declaration="false"
>         encoding="UTF-8" indent="true"/>
>     <p:xslt name="preprocess" version="2.0">
>         <p:input port="stylesheet">
>             <p:document href="preprocess.xsl"/>
>         </p:input>
>     </p:xslt>
>     <p:store href="preprocess.xml"
>         version="1.0" omit-xml-declaration="false"
>         encoding="UTF-8" indent="true"/>
>     <p:xslt name="transform" version="2.0">
>         <p:input port="source">
>             <p:pipe step="preprocess" port="result"/>
>         </p:input>
>         <p:input port="stylesheet">
>             <p:document href="data.xsl"/>
>         </p:input>
>     </p:xslt>
> </p:pipeline>
>
> Here the "preprocess" step implicitly pipes the pipeline's implicit "source" input to its own "source" input.  It also implicitly pipes the pipeline's implicit "parameters" input to its own "parameters" input.
>
> The p:store step implicitly pipes the "preprocess" step's "result" output to its own "source" input.
>
> The "transform" step (apparently) implicitly pipes the pipeline's implicit "parameters" input to its own "parameters" input.  However, it does _not_ implicitly pipe the last "result" output (i.e. from the "preprocess" step) to its own "source" input.  I.e. if I comment out the explicit pipe...
>
>     <p:xslt name="transform" version="2.0">
>         <!--<p:input port="source">
>             <p:pipe step="preprocess" port="result"/>
>         </p:input>-->
>         <p:input port="stylesheet">
>             <p:document href="data.xsl"/>
>         </p:input>
>     </p:xslt>

The fact that the p:store step doesn't have a primary output port is
clearly a mistake.  I think most of us would probably agree.

Meanwhile, I'm not sure fixing that would help you.  The output of
p:store is a element that describes where the document was stored.
You'd still have to fix the port binding because you want the result
of the 'preprocess' step.

Parameters are just broken and we're going to fix that.  All that
specialness with parameter ports will get replaces with equivalent
functionality (for the most part) that isn't an input port.  That will
uncomplicated the story about them and ports.

That is, of course, my opinion until we actually do something about
it.  That said, I think the WG members have the same goal for
parameters.

The brittleness of the defaulting story is much harder.  I'm not
certain how to address this.  The "big picture" problem is that we're
serializing a graph into a tree structure.  You have to "cut" the
graph somewhere.  The sibling arrangement also makes chaining
difficult for situations like you describe.


-- 
--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 Thursday, 20 February 2014 11:32:54 UTC