XProc V2 comments

Hi,

 

This mail contains my comments on the "XProc V2.0 Requirements - W3C First Public Working Draft 5 November 2013" at  <http://www.w3.org/TR/xproc-v2-req/> http://www.w3.org/TR/xproc-v2-req/. 

 

My involvement with XProc has been short but quite intense. In a few weeks I wrote a rather large conversion application with XProc as the "binding" language. Most of the conversion work itself is done with XSLT. 

 

I wrote comments about the sections I think I have something to say about. Sections I don't mention I have no opinion about.

 

Regards,

Erik Siegel

Xatapult

erik@xatapult.nl

+31 6 53260792

 

  _____  

 

Section 2.1 Simplify parameters:

Yes, please. I never liked nor used the whole concept of parameter ports a lot, especially after I discovered the (somewhat hidden) <p:with-param>  instruction. So if XProc 2 wants to abandon parameter ports, fine with me.

There is one nuisance left: When you don't have any parameters to pass (I'm talking about XSLT here), you still have to specify  or an empty parameter port or at least a single <p:with-param> instruction. But most XSLT's don't have parameters... So can we make this optional?

 

Section 2.2 Integrate non-XML documents into pipelines

That would be useful, although I'm happy with the current situation that allows binary documents to pass as <c:data>. So are we getting <p:image-conversion> steps?

When non-XML data becomes a "first  class citizen", things like the cx:decode attribute on a <p:store> must become a more integral part of the standard (and not an extension).

 

Section 2.5 Allow arbitrary XDM values in variables

Yes, please. It would also be nice when strict type checking is introduced here (like in XSLT). So you can speccify something as as="element(a)". Assigning something else than an <a> must then raise an error.

 

Section 2.6 Allow attribute value templates

Yes, yes, yes.

 

Section 2.7 Support a variety of syntactic simplifications

Ok, as long as this accompanied by a thorough and clear specification of which simplifications are possible an what they mean. Otherwise it will be very confusing.

 

Section 3.2 Associate arbitrary metadata with documents

Well, sounds like a superfluous thing. When you need metadata, just wrap the document in another element and add the metadata there. Remove when no longer needed.

 

Section 3.4 Provide improved status information

Yes, something like the XLST <xsl:message>?

 

Section 3.5 Provide a mechanism for importing user-defined functions

Yes, please. Maybe import XSLT stylesheets or XQuery modules that define user defined functions? 

But maybe also: Define XPath functions within XProc itself?

 

Section 3.7 Write a primer

If you ever need a (ghost? co?) writer, mail me.

 

Section 3.8 Consider using XDM everywhere

Why not. It would make the language much more consistent.

 

Section 3.10 Consider additional steps and enhancements

Yes please. I use the zip, file and os related stuff a lot. it would be very convenient if this became part of the core.

 

About p:zip, I have an additional request which actually surprised me that it was not part of the current pxp:zip proposal: On a current pxp:zip, you specify the contents of a zip in a manifest. Fine, but why doesn't this manifest allows you to specify Xproc steps/ports as input for a file in the zip? Maybe exactly like you specify the connection for an input port? Now you have to pass all your input XML through one port and select on base-uri, very awkward. Much simpler if you could specify something like: 

<c:entry name="file.xml">

  <pipe step="some-step" port="result"/>

</c:entry>

Same with inline, document, etc.

Or maybe in shorthand:

<c:entry name="file.xml" step="some-step" port="result"/>