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

Xproc v.next comments

From: Alex Muir <alex.g.muir@gmail.com>
Date: Thu, 11 Oct 2012 14:39:03 -0400
Message-ID: <CAFtPEJZdUA+00-TA8o3u2vcYXGTUy5-91RqV57R9HHwTfvFFSA@mail.gmail.com>
To: public-xml-processing-model-comments@w3.org
Cc: XProc Dev <xproc-dev@w3.org>

I've read through the wiki with the v.next concept. Here are my thoughts.

For me the following are the most important v.next features

   1. http://www.w3.org/wiki/ResourceManager
      1. I note the p:documents concept. I tend to think that for
      simplicity the resource manager would be the way to work with multiple
      2. Choose-Style-Binding
         1. I wonder but don't know if the resource management concept
         could also simplify the binding issue described. Is there an
example of
         3. Generally once a resource manager has been designed how can
      that simplify the syntax?
      1. Are ports and sources required or just resources?
         2. Do we load a parameters file into a resource?
            1.  Does
               1. <p:input port="source">
               <p:variable name="includeRoughAttribute"
                 <p:pipe step="Createi4EnrichMarkup" port="parameters"/>
            2. Become
            1.  <p:load resource="parameters">
               <p:variable name="includeRoughAttribute"
            3. Does resources replace the concept of a pipe and ports?
         1. That would probably make it easier to understand the language
            for most users.
            2. That and altering the term viewport which has nothing to do
            with the ports as you might intuitively expect.
            4. With a resource manager in place could the spec then forbid
      implementations from saving resources without this being specified in the
      code so that the code has more control over memory resources. My current
      process I need to set to run with 2.5gb of memory. Guesstimate that it
      wouldn't use more than 512mb were resources managed effectively.


Least important:

   1. p:sort
      1. Why not just use xslt to sort?


Syntax thoughts

Generally I'm fine with the syntax. Just some things are overly verbose.

For p:xslt why does this need to be a port?

           <p:input port="stylesheet">

Why not just?


Not a fan of this error --- "It is a *static
* (err:XS0055 <http://www.w3.org/TR/xproc/#err.S0055>) if a primary
parameter input port is unconnected and the pipeline that contains the step
has no primary parameter input port unless at least one explicit
p:with-param <http://www.w3.org/TR/xproc/#p.with-param> is provided for
that port. "  It's a little overly complex. If I don't want to add a
parameter to a p:xslt step it should not require a statement suggesting
that I haven't done that.  It should just be empty.


p:group is interesting in that you use it to group steps for as well as for
establishing scope for variables and in that case it's not really clear
until you get error messages telling you about it. I tend to think it's
better to be clear and have a p:variable-scope or some such concept and
keep the p:group for just grouping things without having any scope

Hope all is well
Good luck on the v.next...


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 18:39:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:10 UTC