W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > April 2009

Re: p:choose is poorly and/or incorrectly specified

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

> 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,

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:26 UTC