- 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