Xproc v.next comments

Hi,

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
      documents.
      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
         this?
         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:document
               href="../configuration/i4Enrich-Parameters.xml"/>
                </p:input>
               <p:variable name="includeRoughAttribute"
               select="/c:param-set/c:param[matches(@name,'includeRoughAttribute')]/@value">
                 <p:pipe step="Createi4EnrichMarkup" port="parameters"/>
                </p:variable>
            2. Become
            1.  <p:load resource="parameters">
                 <p:document
               href="../configuration/i4Enrich-Parameters.xml"/>
                </p:input>
               <p:variable name="includeRoughAttribute"
               resource="parameters"
               select="/c:param-set/c:param[matches(@name,'includeRoughAttribute')]/@value"/>
            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">
            <p:document
href="../xslt/end/ConvertFirstOccurenceOfSubsectionToSectionFollowingMDNA.xsl"/>
           </p:input>


Why not just?

 <p:stylesheet
href="../xslt/end/ConvertFirstOccurenceOfSubsectionToSectionFollowingMDNA.xsl"/>
--

Not a fan of this error --- "It is a *static
error<http://www.w3.org/TR/xproc/#dt-static-error>
* (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
implications.



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

Alex
http://ca.linkedin.com/pub/alex-muir/36/ab7/125

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!