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

Serialization parameters as parameter ports

From: Vasil Rangelov <boen.robot@gmail.com>
Date: Sun, 3 Feb 2008 00:24:44 +0200
To: <public-xml-processing-model-comments@w3.org>
Message-ID: <47a4edb2.0405560a.7b5a.5797@mx.google.com>

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
Received on Saturday, 2 February 2008 22:25:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 2 February 2008 22:25:01 GMT