- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Thu, 25 Oct 2007 20:53:53 +0100
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Alessandro Vernet wrote: > On 10/25/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: >> [...] >> This achieves the stated goal, namely that the output defaulting rule >> can be applied w/o arbitrary recursion and analysis through named >> pipelines. > > To reiterate on the argument I made during the call today, it looks to > me that this leads to a situation where to be valid, some pipelines > need to declare their outputs, while others do not. I think this will > create some confusion, as a pipeline author can't just look at the > outputs declared on the pipeline (maybe written by someone else) to > know what the outputs of that pipeline is. I agree with Alessandro. With this definition, I could define a pipeline library none of whose pipelines defined their inputs or outputs, and everything would work absolutely fine. I could even call pipelines from inside my other pipelines and never have a complaint. Until I happened to call one as the last step in a pipeline (perhaps because I just comment out the following code during debugging). Then suddenly I get an error not about the pipeline I'm currently working on, but about the one that it's calling not having defined its outputs. I think this will seem really arbitrary. On the other hand, I understand Henry's (and Richard's) urge to make/keep simple pipelines simple. So what about a rule that says "if a pipeline is called *at all* then it must have declared its inputs and outputs explicitly". This keeps the neat defaulting rules for the common/simple case of a single pipeline to do a quick job, but means that if you're planning to expose your pipelines for other people to call, then you have to take the extra step of declaring the inputs and outputs to the pipeline. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Thursday, 25 October 2007 19:54:03 UTC