Re: Another ('nother) parameters proposal

I can certainly live with this proposal and have no more or less
preference for this over the proposal I sent out.

One minor question/tweak:

On 5/25/07, Norman Walsh <ndw@nwalsh.com> wrote:
>    Now I suppose a user might want to merge parameter-sets, just like
>    they can merge attribute-sets, so perhaps we could allow
>    @use-parameter-sets on p:parameter-set. If we do, then I think
>    the priority (for determining what to do with name collisions) should
>    be that the *used sets* have higher priority. That's possibly
>    counter-intuitive, but it means that in:
>
>    <p:parameter-set use-parameter-sets="#default">
>      <p:parameter name="output-method" value="html"/>
>    </p:parameter-set>
>
>    The output-method parameter passed to the pipeline, if there was
>    one, gets priority over the local one. Otherwise, merging with
>    #default isn't very useful.

I would be very nice for the pipeline author to be able to *force* a
parameter value and not allow it to be overridden by parameters
passed on the "command-line".

A simple addition to this would be to add a 'inherit' attribute
to the 'p:parameter' element that has a default value of 'yes'.  If
you set it to 'no', the only the value specified is bound.  A value
of 'yes' indicates the behavior you described in your proposal.

Also, I assume p:parameter has the same structure as the status
quo and allows the XPath context to be specified by p:pipe, p:document, or
p:inline, right?

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Friday, 25 May 2007 21:12:43 UTC