Re: More defaulting

Norman Walsh wrote:
> / Alex Milowski <alex@milowski.org> was heard to say:
> | On 4/24/07, Norman Walsh <ndw@nwalsh.com> wrote:
> |>
> |> Consider:
> |>
> |> <p:serialize>
> |>   <p:option name="href" value="/tmp/out.xml"/>
> |>   <p:option name="method" value="html"/>
> |> </p:serialize>
> |>
> |> I wonder if we should allow that to be written as:
> |>
> |> <p:serialize href="/tmp/out.xml" method="html"/>
> |
> | I would love to be able to do that!!!
> |
> | I wonder if we should also allow
> |>
> |>   <p:option name="href" value="/tmp/out.xml"/>
> |>
> |> to be expressed as
> |>
> |>   <p:option href="/tmp/out.xml"/>
> |
> | Yes.
> |
> | I have mixed feelings about both of these, but I find myself doing the
> |> latter by accident sometimes and wishing for the former. Now that we
> |> have options and parameters clearly distinct, it doesn't seem totally
> |> unreasonable to do this.
> |>
> |> In both cases, I would expect the attribute values to be taken literally.
> |> If you want a select, you have to do it the long way:
> |>
> |>   <p:option name="href" select="concat($basedir,'foo.html')"/>
> |
> | Sure.
> 
> Everyone else, please weigh in!

I don't view this as defaulting: you're not proposing omitting elements 
or attributes, but providing an alternative syntax that can be used in 
some circumstances (but not in others).

I would be very happy with options-as-attributes if all options were 
always attributes. I think we can even have those whose value would 
otherwise be specified with the select attribute be specified as 
attributes, if we allow attribute value templates:

   <p:serialize href="{$basedir}foo.html" method="html" />

The only drop in functionality is that it would no longer be possible to 
have two options that needed to be evaluated based on different context 
nodes. For example:

   <my:example>
     <p:option name="root1" select="name(/*)">
       <p:pipe step="step1" source="result" />
     </p:option>
     <p:option name="root2" select="name(/*)">
       <p:pipe step="step2" source="result" />
     </p:option>
   </my:example>

This is obviously a rare case, whereas the usability benefits of 
allowing options to be set via attributes will apply across the board.

So what I'd propose is:

(1) Options are set by attributes on steps, which may contain {}s to 
indicate evaluated content

(2) We provide a <p:variable> element to create lexically-scoped 
variables that can be declared and used anywhere within the pipeline

(3) <p:option> is only used to declare options, at the start of 
<p:pipeline> (it has the same relationship to <p:variable> as 
<xsl:param> has to <xsl:variable>)

The example above could then be written:

   <p:variable name="root1" select="name(/*)">
     <p:pipe step="step1" source="result" />
   </p:variable>
   <p:variable name="root2" select="name(/*)">
     <p:pipe step="step2" source="result" />
   </p:variable>
   <my:example root1="{$root1}" root2="{$root2}" />

Compound steps (<p:for-each>, <p:viewport>, <p:group> etc.) could no 
longer contain <p:option>.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Monday, 30 April 2007 08:32:28 UTC