- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 25 May 2007 20:34:04 +0100
- To: public-xml-processing-model-wg@w3.org
Henry S. Thompson wrote: > So after thinking a bit more about this, I'm left with two things at > least I don't like at all: > > 1) Parameter inheritance is now very complicated -- in the absence of > any parameter ports, parameters are effectively inherited and > shadowed on an individual basis, but in the _presence_ of explicit > parameter port bindings, an individual parameter binding may be > hidden even though no parameter of that name was presented to the > relevant parameter port (see example A below). > > And parameter port bindings are shadowed on a whole-document > basis, so that I have to explicitly join parameter documents by > multiple references (see example B below), and parameters set by > parameter port bindings are _not_ visible inside named pipes if > they also happen to use parameter ports (see example C below). Yes. If you want to inherit parameters from the container step with amendments to individual parameters, under Norm's draft you have to explicitly say that you want to do that inheritance. For example: <p:xslt> ... <p:input port="parameters"> <p:pipe step="pipe" source="parameters" /> </p:input> <p:parameter name="foo" value="bar" /> ... </p:xslt> will inherit all the parameters from the pipeline, and either add or override the value of the 'foo' parameter to 'bar'. The other way to do it would be to say that they were inherited by default, but then you'd want a way of *excluding* the parameters that you really didn't want to pass through. I didn't go this route because: (a) I think in most cases you *won't* want to pass through parameters if you're also setting parameters yourself (b) the mechanism above seems fairly straight-forward (c) I couldn't think of a simple mechanism of excluding parameters > 2) In the case where both individual parameter binding and parameter > port binding occur, in at least some cases the engine will have to > compute and make available a synthetic c:parameters document (see > example D below). Obviously I haven't implemented it, but I imagine that implementations could actually pass around a map of name/value pairs and only construct the <c:parameters> document when that was actually required as a standard input to a step. > I have an alternate proposal, which I believe is both much simpler to > explain and to implement, and which provides all the functionality of > the current 'alternative' [2]: > > To the _status quo_ (inherited, scoped, individual parameter > bindings, per [1] as of 10 May), simply add a single new element, > let's call it p:parameters, allowed once only in all steps (including > containers), content model as of p:input, that is > > (p:inline|p:document|p:pipe)+ > > Contents should be a sequence of c:parameters documents, containing > c:parameter*. > > Parameter semantics are unchanged from [1] except that we treat the > c:parameter name-value pairs as if they were p:parameter name-value > pairs on the step, occuring _before_ any explicit p:parameter > elements there. I think that's fine, and I think it's a great idea to allow a sequence of <c:parameters> documents. > That's it -- consistent inheritance and scoping, but the ability to > construct, target and manipulate groups of parameter bindings. Jeni, > Norm -- is there anything you _can't_ do with this mechanism that you > could do with [2]? I don't think that I can pass parameters to a pipeline that I define and then filter those parameters within the pipeline. For example, if I invoke my:funky-pipeline like: <my:funky-pipeline> <c:parameter name="filter1" value="@name = 'N'" /> <c:parameter name="filter2" value="@type = 'date'" /> <c:parameter name="sort1" value="@subtype" /> </my:funky-pipeline> I don't think there's a way, under your proposal, to design <my:funky-pipeline> so that all the parameters starting with 'filter' are directed to one XSLT transformation while those starting with 'sort' are directed to another, or to iterate over the parameters, or anything like that. I could design all my pipelines so that they accept XML documents and options rather than parameters, but I don't really want to force users to create XML documents to pass in parameters to my pipeline. So I could live with this, in the interests of the getting the spec done, but it wouldn't be my first choice. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Friday, 25 May 2007 19:34:22 UTC