Re: Option syntax

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | Norm used comments to draw attention to the fact that the replace
> | option was being set with the value attribute in one place and the
> | select attribute in another. Using the wrong attribute name is very
> | easy to do (especially when the value of the option is an XPath
> | expression and you're using to writing 'select=' to set an XPath) but
> | gives the wrong result without giving any kind of error.
> 
> Yes, this has come up before and we've talked about it a little bit
> but never moved towards fixing it.

I know. I wanted to raise it again because it's one of the five big 
things that make me unhappy about the current language, the others being:

* the whole parameters thing

* the lack of defaulting for inputs (we're all writing pipelines as if 
the default readable port actually provided a default input, but it 
doesn't, so far as I can tell, in the current draft; I believe this is 
just an oversight)

* the lack of composability (i.e. that you can't simply wrap any given 
step in a pipeline, exposing the same signature, and have it work, but 
fixing that would take a fair amount of time, effort and willingness to 
change, which I don't think we have)

* the verbosity of setting inputs (but we spent a long time getting to 
where we are, and I don't see anything obvious we can do about it)

> | 1. Setting the option to a static value must be done through an
> | attribute on the step element; setting to a dynamic value must be done
> | with the current <p:option> syntax:
> [...]
> | 2. Setting the option to a static value must be done through the
> | content of the <p:option> element rather than a value attribute;
> | setting to a dynamic value must be done with the current <p:option>
> | syntax:
> [...]
> | 3. <p:option> only has a value attribute, and we use an attribute
> | value template syntax to set it to a dynamic value:
> [...]
> | I'd be content with any of the above over the status quo (if forced to
> | choose, I'd say 3 was my favourite, then 1, then 2).
> 
> I think I'd rank my choices as 2, status quo, 3, 1.
 >
> I don't feel strongly about 2 vs status quo. I've already expressed
> reservations about introducing AVTs.
> 
> If we *did* introduce AVTs, then I think we'd have to revisit some of
> our other decisions about when and were options are set. At least, I'd
> want to.

Surely, the mapping from:

   <p:option name="foo" value="b{$a}r">
     <p:pipe step="step1" source="source" />
   </p:option>

to the current syntax:

   <p:option name="foo" select="concat('b', $a, 'r')">
     <p:pipe step="step1" source="source" />
   </p:option>

is trivial. Where's the issue?

Cheers,

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

Received on Monday, 28 May 2007 19:24:43 UTC