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

Re: Revised parameters proposal

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 06 Jun 2007 21:55:44 +0100
Message-ID: <46671F50.1050002@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | In fact, I'm not all that convinced that parameter sets will get much
> | reuse, so rather than forcing people to do:
> |
> | <p:pipeline ...>
> |   ...
> |   <p:parameter-set name="my-xslt-parameters">
> |     <p:pipe step="foo" source="result" />
> |     <p:parameter name="view" value="default" />
> |   </p:parameter-set>
> |   ...
> |   <p:xslt use-parameter-sets="my-xslt-parameters">
> |     ...
> |   </p:xslt>
> | </p:pipeline>
> |
> | I think we should allow:
> |
> | <p:pipeline ...>
> |   ...
> |   <p:xslt>
> |     ...
> |     <p:parameter-set>
> |       <p:pipe step="foo" source="result" />
> |       <p:parameter name="view" value="default" />
> |     </p:parameter-set>
> |   </p:xslt>
> | </p:pipeline>
> |
> | The proximity of the construction of the parameter set and the use of
> | the parameter set will help users.
> |
> | [In fact, I think that <p:parameter-set> could be removed from the
> | <p:pipeline> context: if you want to share parameter sets, you can
> | always create a sequence of <c:parameter> documents to hold them.]
> 
> I think that would complicate the defaulting story. Instead of saying
> that the default value for @use-parameter-sets is "#top-level" we
> have to say ... something like:
> 
>   A step that does not contain a p:parameter-set is treated as if it
>   contained a p:parameter-set that contained a pipe pointing to a step
>   that copies the top level parameters. The copying step is also
>   implied if it doesn't exist.

I don't think it needs to be that complicated. If we didn't have 
pipeline-level (named) parameter sets then the only parameter set we'd 
ever need to use would be the pipeline-level one, which means you'd have 
a specific syntax to do it, like <p:import-parameters> or something.

Anyway, I'm happy enough to keep <p:parameter-set> at the pipeline level 
for now (and see how it looks in the draft), but I'd really like to be 
able to use it within step invocations too.

> |>    If the same parameter is specified more than once inside a
> |>    p:parameter-set, the last value specified is used.
> |>
> |>    Having sets isn't very useful if you can't use them, so we also
> |>    need @use-parameter-sets on steps. (For steps not in the pipeline
> |>    namespace, that's spelled @p:use-parameter-sets.)
> |
> | I have a strong preference for using a nested syntax rather than an
> | attribute for constructing the parameter set from other parameter
> | sets. In other words, rather than:
> |
> | <p:parameter-set name="setc" use-parameter-sets="seta">
> |   <p:parameter name="aname" value="3"/>
> | </p:parameter-set>
> |
> | use:
> |
> | <p:parameter-set name="setc">
> |   <p:use-parameter-set name="seta" />
> |   <p:parameter name="aname" value="3" />
> | </p:parameter-set>
> |
> | and rather than:
> |
> | <p:xslt use-parameter-sets="seta setb">
> |   ...
> | <p:xslt>
> |
> | use:
> |
> | <p:xslt>
> |   <p:use-parameter-set name="seta" />
> |   <p:use-parameter-set name="setb" />
> | </p:xslt>
> |
> | The reason is that elsewhere (namely in <p:input>) we use a nested
> | syntax for constructing sequences of documents, and this seems to be a
> | similar kind of thing. It also simplifies things when it comes to
> | figuring out whether parameters in the content or from the used
> | parameter sets get priority (see below).
> 
> I have a preference for attributes. It's not uncommon to use
> attributes to point to stuff: attribute-sets, output parameters, and
> character maps in XSLT, for example.

I wouldn't exactly call attribute sets or character maps common. But 
then I don't do a lot of XSL-FO work.

> That said, you're right about the fact that we use nested elements
> inside p:input.
> 
> I'll vote "concur" on this one if it helps get us finished.

[snip]
> | The other thing from my proposal that I'd like to see here is to allow
> | extension attributes on the <c:parameter> elements, which are simply
> | ignored when a new parameter set is created. It just means that I can
> | use documents to hold my parameter sets and not have to worry about
> | stripping away any annotations I might place on them.
> 
> Yes, I didn't say it, but I intended that extension attributes would
> be allowed.

The spec should also note that they're ignored (not carried through) 
when parameters are passed into a pipeline. In other words, if you pass 
parameters into a pipeline using <p:pipe> then the <c:parameter> 
elements generated from the <p:parameters> step *won't* include those 
extension attributes.

> |> Pipelines that need to perform more complex computations can do so:
> |>
> |>   <p:pipeline>
> |>     <p:parameter-set name="global">
> |>       <p:pipe port="result" step="load-global"/>
> |>       <p:pipe port="result" step="some-top-level"/>
> |>     </p:parameter-set>
> |>
> |>     <p:try name="load-global">
> |>       <p:group>
> |>         <p:output port="result"/>
> |>         <p:load>
> |>           <p:option name="href" value="~/.globals.xml"/>
> |>         </p:load>
> |>       </p:group>
> |>       <p:catch>
> |>         <p:output port="result"/>
> |>         <p:identity>
> |>           <p:input port="source">
> |>             <p:inline>
> |>               <c:parameters/>
> |>             </p:inline>
> |>           </p:input>
> |>         </p:identity>
> |>       </p:catch>
> |>     </p:try>
> |
> | That should be:
> |
> |   <p:catch>
> |     <p:output port="result" />
> |     <p:identity>
> |       <p:input port="source"><p:empty /></p:input>
> |     </p:identity>
> |   </p:catch>
> 
> Right. That was a holdover from when I was thinking of having
> c:parameter*s* documents.

Sure; I just wanted to point it out in case you were going to copy the 
example verbatim into the spec.

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 6 June 2007 20:55:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT