- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Mon, 12 Oct 2009 16:04:03 +0100
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
On 12 Oct 2009, at 15:48, Norman Walsh wrote: > Jeni Tennison <jeni@jenitennison.com> writes: > >> Put another way, what I'm suggesting is: > [...] > > Ok, so...taking this as far as I can... [snip] Yes, that's about what I'm suggesting. > The most troubling part of this approach is the way in which "invalid" > has to percolate through the pipeline and be taken into consideration > in different places: > > 1. When evaluting if all of the branches of a p:choose have the same > signature, ignore any branch that directly contains an invalid > step. If all the branches are invalid, then the p:choose is > invalid. > > 2. When evaluating if the p:try/p:group and p:catch branches of > a p:try have the same signature, ignore either clause if it > contains an invalid step. If the p:catch includes an invalid > step, then the p:try is invalid. > > 3. If a subpipeline contains an unrecognized step (not in a p:choose > or p:try/p:group), then that subpipeline has to be marked > invalid. > > If you don't do this, then I don't think it's possible to build the > dependency graph. I agree, and I think this is correct. If someone's trying to use a v2 step within a v1 processor then they have to guard it within a <p:choose> or a <p:try>. The percolation will continue with steps declared by invalid <p:declare-step>s of course. Just wondering, because I didn't spot it, is there anything similar in place for implementation-defined steps? Is it possible to write pipelines that can be used with multiple processors that support different extensions? Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Monday, 12 October 2009 15:04:32 UTC