New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.7.5 Syntax: allow p:inline to be optional. #38

Closed
ndw opened this Issue Aug 22, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@ndw
Collaborator

ndw commented Aug 22, 2014

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.

@ndw ndw added the requirement label Aug 22, 2014

@xproc xproc added the must label Aug 22, 2014

@ndw ndw added this to the XProc 2.0 LC milestone Aug 25, 2014

@xquery xquery self-assigned this Oct 1, 2014

@xquery

This comment has been minimized.

Collaborator

xquery commented Oct 1, 2014

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

This comment has been minimized.

Collaborator

ndw commented Oct 1, 2014

That all sounds reasonable and correct to me.

@vojtechtoman

This comment has been minimized.

Collaborator

vojtechtoman commented Oct 2, 2014

I like the proposal.

@xquery

This comment has been minimized.

Collaborator

xquery commented Nov 5, 2014

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

@xquery

This comment has been minimized.

Collaborator

xquery commented Nov 10, 2014

@xquery

This comment has been minimized.

Collaborator

xquery commented Nov 12, 2014

(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

xquery added a commit to xquery/xproc-vnext-spec that referenced this issue Nov 19, 2014

xquery added a commit to xquery/xproc-vnext-spec that referenced this issue Nov 19, 2014

ndw added a commit that referenced this issue Nov 20, 2014

Merge pull request #120 from xquery/xproc20
issue #38 - implicit p:inline

@ndw ndw closed this Nov 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment