W3C home > Mailing lists > Public > xproc-dev@w3.org > April 2009

Re: Compute attribute value with set-attribute

From: Florent Georges <fgeorges@gmail.com>
Date: Tue, 7 Apr 2009 18:02:15 +0200
Message-ID: <ebaca5bf0904070902k53fd7f62xf32d25df8f0eb8f7@mail.gmail.com>
To: James Sulak <jsulak@gmail.com>
Cc: XProc Dev <xproc-dev@w3.org>
2009/4/7 James Sulak wrote:

> This is just an idea; I'm not sure if it's actually a good one.
> In practice, I doubt this problem will happen much, since steps
> generally have a default readable port available.  And the
> current approach has the virtue of consistency, even if it is
> more verbose.

  I am a bit concerned about that also, but the other way
around :-) I wonder if this is really intuitive to implicitly
bind a step result to a p:with-option.  In my humble opinion, it
is intuitive to connect a step's output to the next step's input.
This is less obvious that a step's output is connected to the
following step's with-options that are not explicitly bound to
any port.

  I do not mind to add a p:empty (well, if I know I have to :-/)
but I wonder if this is really helpful to implicitly bind
p:with-option to the default readable port, instead of forcing
the user to explicitly bind it if she wants to.

  I guess that will give a processor less opportunities to detect
user's errors while this does not really improve readibility or
conciseness.  In the following example:

    <p:identity name="you">
       <p:input port="source">

    <p:add-attribute match="elem" attribute-name="a">
       <p:input port="source">
       <p:with-option name="attribute-value" select="
           concat('Hello, ', what, '!')"/>

I am not sure this is really more readable than:

    <p:with-option name="attribute-value" select="
        concat('Hello, ', what, '!')">
       <p:pipe step="you" port="result"/>

and in the later I am sure the user intended to bind the
with-option to the result of the step "you."

  Well, just my humble opinion.


Florent Georges
Received on Tuesday, 7 April 2009 16:02:57 UTC

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