W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2012

Thoughts on a concept to ease and speed xproc development

From: Alex Muir <alex.g.muir@gmail.com>
Date: Thu, 11 Oct 2012 11:09:33 -0400
Message-ID: <CAFtPEJbxKOR=aMydu1PzLEnjZ+udbFGcHt-S7NE1uVxo0t_RKg@mail.gmail.com>
To: XProc Dev <xproc-dev@w3.org>
Cc: public-xml-processing-model-comments@w3.org


The process of a user developing with xproc is constrained in that xproc
essentially provides a wrapper to execute other processes such as p:xslt
with some other limited yet useful abilities. Given this constraint I
wonder if the design can be improved to harness an effective development
strategy that both reduces lines of code and speeds development.


A while back I decided to create a tweak of the p:xslt step which basically

1. A version of logging that has a boolean value to turn off the log to let
me know that process has got to that p:xslt step when debugging

       <p:with-option name="message" select="'
       <p:with-option name="logging" select="$logging"/>

2.  a p:store with a boolean to write the xml file or not preserving the
state of the content prior to the p:xslt for later debugging the p:xslt

         <p:with-option name="save" select="$debug"/>
         <p:with-option name="href"

3.  p:xslt

 <p:xslt name="NormalizeContentAndCreateInitalXMlStructure" version="1.0">
       <p:input port="stylesheet">
       <p:with-param name="svnRevision" select="$svnRevision"/>
       <p:input port="parameters">

Combining them resulted in:

 <mh:xxslt name="NormalizeContentAndCreateInitalXMlStructure" version="1.0"
mh:doc="Create the intial Document structure">
       <p:with-option name="debug" select="$debug"/>
       <p:with-option name="logging" select="$logging"/>
       <p:with-option name="debugPathAndFileNamePrefix"
       <p:input port="stylesheet">
        <p:document href="filename.xsl"/>
       <p:with-param name="svnRevision" select="$svnRevision"/>

( Also removed the empty  <p:input port="parameters"> )

 1. Greatly improved the readability of my code and shaved ~800 lines of
code out of around 3000.
 2. Is useful because when debugging a particular p:xslt because the input
file is easily available if I set debug to be true and run the process.

But wait there's more... ;)

So assuming xproc steps that execute some other external process to modify
the xml such as a p:xslt would in future versions provide the extra
abilities, to log that you've arrived at that location, output what the
content is before arriving both using debug values, there are some
enhancements and development consequences that result.

1. Given that a unique p:xslt step
name="NormalizeContentAndCreateInitalXMlStructure" exists it can be used to
specify the file name of the xml file that is being written out to be used
later as debug input in a transformation scenario. Currently I'm using the
name of the xslt file and then add the debug folder location with a prefix
to be unique. I suppose I had not at the time thought of using the step
name (and well I'm not sure that name is available in calabash code, I
haven't checked)

       <p:with-option name="debugPathAndFileNamePrefix"

2. Automatic build of Oxygen project file with transformation scenarios

A script could converts an xpl + parameter file into an oxygen project
scenario with parameters all configured. This would be useful as a
developer. All the information to do this exists outside of oxygen given
this concept and yet unless you agree on some concept like the one I'm
describing at least I don't think Oxygen developers would have a way of
currently making such a nice automation feature.


Given all this generally to ensure that some concept like this would work 3
extra elements would be required. Perhaps like so

 <p:xslt name="NormalizeContentAndCreateInitalXMlStructure" version="1.0"
mh:doc="Create the intial Document structure">
       <p:output-debug-file select="$debug"/>
       <p:output-log select="$logging"/>
       <p:debug-folder select="$debug-output-folder"/>
       <p:stylesheet href="filename.xsl">
         <p:with-param name="svnRevision" select="$svnRevision"/>

I suppose they could be optional as well which then would just result in
the false case and loss of described functionality.

       <output-debug-file select="false"/>
       <output-log select="false"/>





Love African Kora Music? Take a moment to listen to Gambia's - Amadu
Diabarte & Jali Bakary Konteh www.bafila.bandcamp.com Your support keeps
Africa's griot tradition alive... Cheers!
Received on Thursday, 11 October 2012 15:10:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:05 UTC