- From: Norman Walsh <ndw@nwalsh.com>
- Date: Tue, 21 Apr 2009 08:34:54 -0400
- To: public-xml-processing-model-comments@w3.org
- Message-ID: <m2bpqq18y9.fsf@nwalsh.com>
"Henry S. Thompson" <ht@inf.ed.ac.uk> writes: > Toman_Vojtech writes: > >> If we add a primary output port to p:error, we will have to decide >> whether it produces sequences (possible problems with other subpipelines >> whose outputs *don't* produce sequences), or not (possible problems ith >> other subpipelines whose outputs *do* produce sequences). > > Yeah, I thought about that but didn't say anything, because it > depressed me :-( > > I wonder if we should reconsider the exact nature of the constraint on > outputs across subpipelines in choose and try. Since we allow > sequence-out->single-in connections, couldn't we allow both > sequence-out and single-out in choose/try subpipes, with the implicit > casting of the single-outs to sequence-out iff any branch has an > explicit sequence-out? I guess we could do that. Since, as you say, it isn't a static error to connect a sequence-out to a single-in, I guess it wouldn't do any harm. > As far as I can see this would not change the behaviour of any > currently-allowed pipeline, and it would, together with making the > primary output of p:error a sequence-out port (always 0-length), would > solve the problem. > > Surely the 90% case for p:error will be in a branch of a choose or > try, so it is worth fixing this. . . Yes, I think that might be the way to go. Be seeing you, norm -- Norman Walsh <ndw@nwalsh.com> | Vision is the art of seeing things http://nwalsh.com/ | invisible.-- Swift
Received on Tuesday, 21 April 2009 12:35:39 UTC