Re: Options or parameters

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norm,
|
| Norman Walsh wrote:
|> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> | Norman Walsh wrote:
|> |> 2. Allow compound steps to declare both options and parameters.
|> |
|> | I'm kinda happy with this for now. (I'll argue for renaming "p:option" to
|> | "p:variable" in this context later.)
|>
|> That's going to be a hard sell. I expect implementations to allow me
|> to set values for options (and parameters) on the command line.
|> There's precedent in XSLT for doing this with parameters and there's
|> lots of precedent for command line options (so we can pun a little bit
|> and overload that term).
|>
|> Setting variables from the command line would strike me as quite odd.
|
| You misunderstand me. I think that <p:option> as an initial child of
| <p:pipeline> makes absolute sense, because these are things that you set at the
| command line. I think that <p:option> as an initial child of <p:group>,
| <p:for-each> etc. is really weird, because you don't invoke <p:group>,
| <p:for-each> from the command line. Using the name <p:variable> in this context
| makes a lot more sense and gels with every programming language I know.

Ah, I see where you're going now.

On the one hand, I think you're right. On the other, I'm not sure I want
XProc to have p:variable, p:option, *and* p:parameter.

On balance, I think I prefer overloading option on p:group and friends
even if that's a little weird.

| I called them parameter sets before. Around about
| http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0030.html

At the end of that message, you have an example that uses two parameter
sets, but I don't see how parameters get placed in those sets.

| I do think it's unwieldy to use namespaces to name sets of parameters,
| especially when the names of parameters can reasonably be QNames.

It could be unweildy, but I think the unweildy cases are far enough from
the common case that adding more complexity to make them less unweildy
might not be worth it for V1.

| At the very least I'd expect pipelines that accept parameters to declare that
| they accept parameters with (something like):
|
|   <p:parameter name="*" />
|
| It doesn't seem a giant leap from there to say that they can declare the
| namespace of the parameters that they accept, with (something like):
|
|   <p:parameter name="config:*" />

Yes, that's what I thought you meant.

| I am not suggesting that they can declare the (local) names of the parameters
| that they accept: if they knew that, it'd be an option.

Note that you couldn't, with the current language, prevent

  <p:parameter name="config:p1" />
  <p:parameter name="config:p2" />

etc. Not that I think that's worth worrying about.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The years teach us much which the days
http://nwalsh.com/            | never knew.-- Emerson