Re: Options and parameters proposal

On 3/7/07, Jeni Tennison <jeni@jenitennison.com> wrote:
>
>
> Hi,
>
> Norman Walsh wrote:
> > On today's call, we seemed to be approaching consensus on having
> > p:option for configuration options and p:parameter for component
> > parameters.
>
> I think this is a step in the right direction. What bothers me is that
> there's only one set of parameters for a given component, and I think we
> need to the flexibility of having any number of sets.
>
> What if I wanted to define a pipeline that used two transformations,
> both of which used parameters. At the moment, the only way to
> distinguish between the two sets of parameters would be to use different
> namespaces for them. I think that's too much of a burden, particularly
> as it places constraints on the XSLT stylesheets themselves.
>
> Or consider Alessandro's HTTP component, which had a set of HTTP headers
> and a set of request parameters.
>
> I suggest that we have named parameter sets. Something like:
>
> <p:http>
>    <p:option name="uri">...</p:option>
>    <p:parameter-set name="headers">
>      <p:parameter name="User-Agent">...</p:parameter>
>      <p:parameter name="...">...</p:parameter>
>    </p:parameter-set>
>    <p:parameter-set name="request-parameters">
>      <p:parameter name="...">...</p:parameter>
>      <p:parameter name="...">...</p:parameter>
>    </p:parameter-set>
> </p:http>



This is where I depart and say that this looks a lot like an
input.  You could just use a port on the http component.

The way I solved for the HTTP component in smallx was completely
different in that the HTTP component consumes a vocabulary
that lets me completely control the HTTP response, entity body, etc.

That input looks like:

<http:response status="200">
<http:header name="Location">...</http:header>
<http:header name="Special">...</http:header>
<http:entity content-type="application/atom+xml">
<http:body>
<feed xmlns="http://www.w3.org/2005/Atom"> ...</feed>
</http:body>
</http:entity>
</http:reponse>

...this way I can do things like multi-part response, special
serialization controls, etc.

I think that using XML inputs is a good design pattern and one that we
already
support.  While the idea of have "structured" parameters is something I've
considered and even sent a proposal to the list about allow lists of values
for
a particular parameter, I think all of these will overly complicate our
language
and seriously overlaps with XML document inputs.

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