p:function (a.k.a. a standard mechanism for XPath extensions within XProc)

I realize I'm opening a can of worms, possibly ending up in causing much
delay in the spec's development, but as XSLT 1.0 has shown, it's a REALLY
important thing to consider. I'd say it is as important as providing means
of creating custom steps (which has been available since the first draft I
have seen thankfully).

I'm talking about extending the XPath function library. XProc uses
"pipelines" or "steps" in a way XSLT uses "templates". But like XSLT, XProc
uses XPath to select different things in XML documents. And like XSLT 1.0,
XProc doesn't yet have a standard mechanism to extend the XPath function
library.

In the case of XSLT, EXSLT had to fill in this gap before they could make
anything really great*. XProc shouldn't repeat that same mistake. The spec
should specify such a mechanism so that pipeline authors don't shy away from
XPath extensions just because they "may not be supported" or "are hard to
detect and work around". A standard, mandatory element for declaring
functions that work within the pipeline would solve this problem.

Naturally, as by the title, I propose this element be called "p:function"
and as you may guess already, it should contain a sub pipeline. Since
pipelines always end with an XML document, whereas XPath may also end with
other types (in the case of XPath 2.0 - sequences), I suppose there should
also be something that would extract some contents of the final result port
and cast it to a specific "literal" type, similar to EXSLT's func:result
element.

XProc now faces a bigger challenge then what XSLT has had to solve, which
where the "can of worms" lies - compatibility between both XPath 1.0 and
XPath 2.0. This extension mechanism should work in both XPath 1.0 and XPath
2.0, meaning you can't just copy the model from the XSLT 2.0 spec or the
EXSLT function element (renaming "param" to "option" in either case). It's
sure to be based on it, but it should either somehow be limited to what
works in both versions (and in a way that could be "added upon" instead of
being reinvented in XProc 2.0) or a completely new model should be made that
is specific to what XProc has to offer and has to comply with (though since
the end result is XML again, the situation is not THAT much different).


* by that I mean implementations of other functions. Any XSLT processor
which implements func:function could safely be assumed to be able to run any
other extension that has a function implementation (provided the stylesheet
author downloads it and includes it of course). A processor which does NOT
implement it can't be relied on for any functions, other than the ones it
explicitly claims to support. All that in turn creates portability problems.

Regards,
Vasil Rangelov

Received on Tuesday, 4 December 2007 18:35:25 UTC