W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > March 2007

Re: Options and parameters proposal

From: Alex Milowski <alex@milowski.org>
Date: Wed, 7 Mar 2007 08:02:46 -0800
Message-ID: <28d56ece0703070802i375d076cwd7834a997268a7dd@mail.gmail.com>
To: public-xml-processing-model-wg@w3.org
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">
<feed xmlns="http://www.w3.org/2005/Atom"> ...</feed>

...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
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
a particular parameter, I think all of these will overly complicate our
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

Bertrand Russell in a footnote of Principles of Mathematics
Received on Wednesday, 7 March 2007 16:04:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC