W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > March 2008

[CLOSED] Re: Serialization parameters as parameter ports

From: Alex Milowski <alex@milowski.org>
Date: Thu, 6 Mar 2008 08:47:50 -0800
Message-ID: <28d56ece0803060847u688abcd4k266facba231c542c@mail.gmail.com>
To: "Vasil Rangelov" <boen.robot@gmail.com>
Cc: public-xml-processing-model-comments@w3.org

The working group considered this feature but concluded that we would not
attempt this in V1.  There is a work around in that you can create a document
containing the option values and select the options values from that document
using a group which contains the serialization.

Please see the minutes on this comment:

   http://www.w3.org/XML/XProc/2008/02/07-minutes#action02

Thanks.

On 2/2/08, Vasil Rangelov <boen.robot@gmail.com> wrote:
>
>  It would be great if serializations parameters for and from steps could be
>  written/read as (non-primary) input/output ports, and I don't see any reason
>  why it should not be done.
>
>  XProc already provides the facilities for that with its kind="parameter"
>  ports.
>
>  Some use cases I have in mind (and some pseudo code to illustrate them) are:
>
>  1. Store the result of an XSLT transformation (i.e. as a file) with
>  serialization options as by the stylesheet.
>  <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
>         <p:xslt name="result">
>                 <p:intput port="stylesheet">
>                         <p:document href="stylesheet.xsl"/>
>                 </p:input>
>                 <!-- Once finished, a non-primary output port named
>  "serialization" (for example) is added to the list of output ports-->
>         </p:xslt>
>         <p:store href="result.xml">
>                 <p:input port="serialization" kind="parameter">
>                         <p:pipe step="result" port="serialization"/>
>                 </p:input>
>         </p:store>
>  </p:pipeline>
>
>  2. Allow an XSLT step to override any serialization options from the
>  stylesheet.
>  <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
>         <p:xslt>
>                 <p:intput port="serialization" kind="parameter">
>                         <p:inline>
>                                 <c:parameter-set>
>                                         <!--With this, the output would
>  always be indented, or at least, that's what the "serialization" output port
>  will contain-->
>                                         <c:parameter name="indent"
>  value="yes"/>
>                                 </c:parameter-set>
>                         </p:inline>
>                 </p:input>
>                 <p:intput port="stylesheet">
>                         <p:document href="stylesheet.xsl"/>
>                 </p:input>
>                 <!-- Once finished, a non-primary output port named
>  "serialization" (for example) is added to the list of output ports-->
>         </p:xslt>
>  </p:pipeline>
>
>  3. Allow pipeline processors to serialize the output of a pipeline based on
>  the serialization options from a stylesheet transformation. OK, this
>  particular case would require that p:serialization is made to be able to
>  receive parameters supplied on a port, possibly clarifying that any
>  attributes present on p:serialization override any supplied on the port. I
>  believe it's all well worth it.
>  <p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
>         <p:xslt>
>                 <p:intput port="stylesheet">
>                         <p:document href="stylesheet.xsl"/>
>                 </p:input>
>                 <!-- Once finished, a non-primary output port named
>  "serialization" (for example) is added to the list of output ports-->
>         </p:xslt>
>         <!--The "options-port" receives serialization options from the
>  serialization port,
>         but doesn't indent the output, regardless of what the port says-->
>         <p:serialization port="result" options-port="serialization"
>  indent="no"/>
>  </p:pipeline>
>
>  XProc processors should (I think) ignore serialization options they can't
>  provide (or which they just don't recognize as valid options), or it could
>  be a dynamic error (maybe even statically if the option is embedded as with
>  the example). From a pipeline author's point of view, I really don't care.
>
>  Anyway, if this is to be declined for V1, how could you do any of these
>  scenarios with what's available now?
>
>
>  Regards,
>
> Vasil Rangelov
>
>
>
>


-- 
--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, 6 March 2008 16:48:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 March 2008 16:48:17 GMT