- From: James Fuller <jim@webcomposite.com>
- Date: Wed, 1 Oct 2014 17:30:40 +0200
- To: XProc WG <public-xml-processing-model-wg@w3.org>
To make things easier to use and author we are proposing new p:inline
syntax behaviour where p:inline is optional.
For example;
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0">
<p:output port="result"/>
<p:serialization port="result" indent="true"/>
<p:identity xmlns:a="http://example.com/a"
xmlns:b="http://example.com/b"
xmlns:c="http://example.com/c">
<p:input port="source">
<p:inline>
<doc>
<b:part/>
</doc>
</p:inline>
</p:input>
</p:identity>
</p:declare-step>
could be
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0">
<p:output port="result"/>
<p:serialization port="result" indent="true"/>
<p:identity xmlns:a="http://example.com/a"
xmlns:b="http://example.com/b"
xmlns:c="http://example.com/c">
<p:input port="source">
<doc>
<b:part/>
</doc>
</p:input>
</p:identity>
</p:declare-step>
The elements that can contain p:inline are;
p:input
p:output
p:parameter
p:with-option
p:variable
p:with-param
p:iteration-source
p:viewport-source
p:xpath-context
I think the crux of this syntax change is to define the heuristics to
discriminate the allowable sibling elements;
p:empty
p:document
p:data
p:pipe-info
p:documentation
p:namespaces
That is if we intended to inline an element from XProc own namespace,
clearly the following would not work.
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0">
<p:output port="result"/>
<p:identity>
<p:input port="source">
<p:pipeinfo>my clever information</p:pipeinfo>
</p:input>
</p:identity>
</p:declare-step>
In this situation we would have to resort to using an explicit p:inline.
<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="1.0">
<p:output port="result"/>
<p:identity>
<p:input port="source">
<p:inline>
<p:pipeinfo>my clever information</p:pipeinfo>
</p:inline>
</p:input>
</p:identity>
</p:declare-step>
This is exactly the kind of edge case that we should ask authors to
use when they mean 'something else'.
So the heuristic roughly is;
Any element which can contain a p:inline can alternately contain
inline content (as long as its not in XProc own namespace) which will
be wrapped in a document node and treated exactly as its set out in
XProc spec section 5.12.
If the author wants to exclude inline prefixes then they will need to
explicitly use p:inline.
Similarly, where it is intended to inline an element from XProc's own
namespace, such as
(p:empty|p:data|p:namespaces|p:pipe-info|p:documentation) then an
explicit p:inline will be required, otherwise an appropriate error
will be thrown.
Lastly, if the author intends to include multiple inline document
nodes then multiple explicit p:inline(s) would then be required with
no mixing of implicit and explicit p:inline behaviour allowed.
I will be tracking this spec task here
https://github.com/xproc/specification/issues/38
Feel free to comment here (or there).
J
Received on Wednesday, 1 October 2014 15:31:12 UTC