Re: Option syntax

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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

Yeah. I hope we can come to some resolution on that soon.

| * 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)

Hah. I see what you mean. Yes, I think that's an oversight. The description
of p:input should include:

  If no binding is provided for a p:input, it is bound to the default
  readable port.

| * 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)

Right. That's tricky.

| * 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)

Yes. Making them less verbose would require going back to attribute
co-constraints, I think, and I don't have any stomach to go there. But
neither do I find the current syntax unbearable.

|> 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?

The issue is that it's a new feature. The feature will have to be
explained, all of the attributes will have to specify whether or not
they are AVTs, the XPath context for AVTs will have to be described,
the escaping rules for AVTs will have to be discussed, the interaction
of AVTs with other decisions we've made will have to be analyzed, etc.

There's nothing that can't be done, but we'll never finish if we don't
stop adding new features.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The happiest people seem to be those
http://nwalsh.com/            | that have no particular reason for
                              | being happy except that they are
                              | so.--W. R. Inge