2.7.5 Syntax: allow p:inline to be optional.

[ndw]

XProc 1.0 offers relatively few default behaviors, requiring instead that pipelines specify every construct fully. User experience has demonstrated that this leads to very verbose pipelines and has been a constant source of complaint. XProc 2.0 will introduce a variety of syntactic simplifications as an aid to readability and usability, including but not limited to:

Allow p:inline to be optional.

[xquery]

http://www.w3.org/TR/xproc-v2-req/#syntax

To make things easier to use and author we are proposing new p:inline syntax behaviour where p:inline is optional.

<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>

would 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>

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 change is what are the heuristics to discriminate the following potential sibling elements

• p:empty
• p:document
• p:data
• p:pipeinfo
• 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>

and would have to resort to

<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:pipeinfo|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.

[ndw]

That all sounds reasonable and correct to me.

[vojtechtoman]

I like the proposal.

[xquery]

note- probably need to reparse/discuss default element ns for an element that defines no ns

[xquery]

publishing properly

http://xquery.github.io/xproc-specification/langspec/xproc20/head/

now with diffs

[xquery]

(I've learned how to push github around with this issue ... apologies for the churn ... I will leave the various commits here (instead of squashing them into one) as a testament to my ignorance.)

spec with changes
http://xquery.github.io/xproc-specification/langspec/xproc20/head/

diff
http://xquery.github.io/xproc-specification/langspec/xproc20/head/diff.html

for discussion at 12/11/14 meeting