Re: !result in components

On 5/29/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / "Innovimax SARL" <innovimax@gmail.com> was heard to say:
> |> For that matter, what would constitute consistent? If I pass a DocBook
> |> document to an XSLT step and I get an HTML document out, how is that
> |> consistent?
> |
> | It is consistent because it is the same content in another form (or format)
>
> Only if that's what the stylesheet does. Stylesheets are free to
> produce any output at all, possibly not related to the input in the
> slightest. (Should stylesheets that accept no input document at all
> use a different port?)
>
> Steps read their inputs and produce their outputs. The store step
> reads its input and, as its output, produces a document that
> identifies the location where the document was stored. That seems
> reasonable to me.

Ok fair enough

>
> |> This would require the invention of some entirely new mechanism and
> |> I'm strongly opposed.
> |
> | It is not really new
> | It is strictly equivalent as today's
> |
> | <p:count name="count"/>
> | <p:option name="$count" select="@value">
> |  <p:pipe step="count" port="result" />
> | </p:option>
>
> Except that you can't write that today. An option can't occur after
> a step. I suppose you could do that with an intervening group, but
> I still don't think it's "strictly equivalent".

Hum...
the definition of pipeline is

<p:pipeline
  name? = NCName
  p:ignore-prefixes? = prefix list>
   ((p:input |
    p:output |
    p:option |
    p:parameter |
    p:import |
    p:declare-step |
    p:journal)*,
    subpipeline)
</p:pipeline>

so you can have p:option after p:step !!



>
> At present, we have no mechanism for a step to manufacture a variable
> in the XPath context of the pipeline and I have no desire to introduce
> such a mechanism.

Ok I get your point

>
> | and it has the advantage of pushing simple types data into options
> | instead of XML files
>
> Except for the simple types that I want to read from other steps, like
> XSLT.

Are you just saying that we can get p:option out of file, but not the opposite ?



>
> |> But having the result of p:store be the same as its input seems
> |> unnecessary.
> |
> | That's not mandatory in my proposal. I could leave with p:store having
> | NO output at all
>
> I prefer the status quo.
>

Mohamed

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Monday, 4 June 2007 22:06:37 UTC