XProc things for our upcoming meeting

Hi all,

 

Our meeting 6+7 February in Prague is coming soon (and please tell me it's
still on, otherwise I'll be stuck in Prague for two days with nothing really
to do.). I hope you don't mind that I open the discussion about what should
be on the agenda with some of my hobbyhorses. 

 

Beside discussion points about XProc there is another thing: In the last few
months I've been working on a book about XProc and in doing that I
encountered a lot of things I would like to discuss or have clarified. I
hope we can find time for that (either during of outside the meetings). If
you're interested I can send the latest draft of the book by the time we'll
meet.

 

For on the XProc agenda I would like to propose to discuss at least the step
library: 

*	The current step library seems very much like the V1 version to me.
I personally (so feel free to disagree) have a strong need for all the
EXPath extension steps functionality, especially the ones for working with
files (directory overviews, delete, copy, move, etc.) and zips (reading,
creating). So: Are we going to incorporate EXpath as-is, are we going to
incorporate them as standard XProc steps (which might be as simple as
changing the step's type namespace)? If so as optional or mandatory step? Or
do we keep them outside the specs? 
*	If incorporating zips is in, I would like to discuss a slightly
different functionality regarding writing them (feeding it with a manifest
that can also read from output ports). I have no idea how difficult it would
be to implement and of course that might be a factor in the decision making.
*	Could we add steps for (I know you can do this with custom steps,
but this is so common.)

*	Recursive directory listings (just extend the current p:directory?)
*	Tee-ing to a file (IMHO: an invaluable and very easy to use debug
tool. Much easier and more low-threshold solution than the current proposal
about diagnostics. We could have both). Add a disable option to the step so
you can easily switch it off when not debugging.
*	Something for creating a file/directory structure on disk using some
manifest. The manifest should specify where to write (path) and what to
write (inline XML, take it from an output port somewhere, copy it from an
URI, etc.). The same functionality I would like to have for creating zips.

 

Another thing I'm specifically interested in are the specifics of importing
function libraries from XQuery/XSLT.

 

 

 

On the clarification front I hope we can find some time to discuss this and
others:

*	Shouldn't the p:declare-step/@xpath-version be an xs:decimal?
*	You need maps in a step's prolog for specifying output
serialization. But you can't use variables there, so these will be "fixed"
maps, specified in full at the location where they're needed. Would it be an
idea to allow variable declarations in between p:input/p:output/p:option
elements? 
*	Why is the @parameters on the p:load an AVT?
*	What is the default value of @expand-text?
*	The explanation of the serialization parameters is not very
detailed. Where can I find more information? (e.g. method is unexplained and
has no value list, what do the normalization-form-s do, etc.)
*	What is the default value of p:option/@required
*	Why does the use of @pipe exclude the use of p:pipe, p:document and
p:inline on a p:with-input? Seems unnecessary.
*	What does this mean with the p:inline: It is a static error
(err:XS0071XPS) if the content type value specifies a character set and the
encoding attribute is absent.
*	I don't understand the example given for p:namespace. I must
honestly say I no longer understand p:namespace at all, even I remember
understanding it more-or-less in Aachen. 
*	What happens when on a p:load you set dtd-validate to true and the
doc has no DTD ref

 

Hope to see you all in Prague,

Erik Siegel