Reading document properties in a step-evaluated XPath

[rdeltour]

XPath extension functions are only available in processor-evaluated XPath expressions. This is OK for most functions, but with the introduction of p:document-properties –which takes a document node as parameter– it would become useful to be able to use it in step-evaluated expressions.

Consider the following scenario: I want to be able to filter a sequence of documents based on their content types. I would like to be able to do:

<p:split-sequence test="map:get(document-properties(/),'content-type') eq 'application/vnd.foobar+xml'"/>

which can only be currently achieved with

<p:for-each>
   <p:choose>
      <p:when select="map:get(document-properties(/),'content-type') eq 'application/vnd.foobar+xml'">
         <p:output port="result" primary="true"/>
         <p:identity/>
      </p:when>
      <p:otherwise>
          <p:output port="result" primary="true">
              <p:empty/>
          </p:output>
          <p:sink/>
      </p:otherwise>
</p:for-each>

[ndw]

Discussed here: http://www.w3.org/XML/XProc/2015/03/11-minutes.html

Alex to flesh out this issue with more detail.

[alexmilowski]

The various document properties would be very useful in a variety of contexts:

• within expressions (e.g., "select" attributes) in pipeline constructs
• within various steps that use XPath (e.g., XSLT or XQuery)
• within AVT expressions

This would allow the same expression to be used in a variety of context just via "cut-n-paste" by the developer.

Unfortunately, this puts a burden on implementors to modify the XPath implementation used in every step as well as the pipeline processor. Further, if the functions were only optionally available, the pipeline necessary to extract them would radically change depending on whether the values were extracted via the pipeline step expressions or within a transform (e.g., XSLT or XQuery).

While this sounds like a promising feature, I believe we need more motivating use cases before we place this burden on implementators.

[rdeltour]

Thanks for the detailed look Alex.

While this sounds like a promising feature, I believe we need more motivating use cases before we place this burden on implementators.

What would you call a motivating use case? (if replacing a 13-line pipeline with a 1-liner isn't compelling enough 😉 )
Also, I would be interested in better understanding the extent of the burden on implementations (my memories of Calabash's internals on that point are too blurry), is it more than e.g. registering a custom function to the Saxon context(s)?
I, for one, would obviously prefer a priority of constituencies à la HTML ("users over authors over implementors over specifiers over theoretical purity"), but of course it's easier said than done when I'm a user and neither an author nor an implementor 😛.

[ndw]

Pushing off a little further absent a use case.