- From: Innovimax SARL <innovimax@gmail.com>
- Date: Fri, 22 Jun 2007 01:08:36 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
On 6/21/07, Norman Walsh <ndw@nwalsh.com> wrote: > / "Innovimax SARL" <innovimax@gmail.com> was heard to say: > | On 6/7/07, Norman Walsh <ndw@nwalsh.com> wrote: > |> Right now, we have support for 1 or 0-or-more documents as input. > |> What's missing is support for 1-or-more and 0-or-1. > |> > |> I can think of some reasons for 0-or-1 (an optional configuration > |> input, for example), but I can't think of any uses for 1-or-more. > | > | 0-or-1 is already in use in the spec : look at p:option/p:parameter > | but since zero is authorized, why an empty sequence wouldn't be > | authorized here ? > > Options, parameters, (and xpath-context and viewport-source) are > special cases. You can't declare an atomic step such that it takes 0 > or 1 documents on an "ordinary" input port. You can only say 1 or 0 or > more. > > You can pass an empty sequence to p:option and p:parameter. You can > pass an empty sequence to p:xpath-context too, but your expression > better return an empty node set. A p:viewport-source does require > exactly one document. Even with a p:pipe element pointing to an empty sequence ? > > |> With that in mind, does anyone want to advance arguments for change > |> in this part of the spec? > | > | some DTD like > | > | (nothing) or cardinality="" 1-1 > | cardinality="*" 0-or-more > | cardinality="?" 0-or-1 > | cardinality="+" 1-or-more > > Yes, we could do that. I'd like to think of something more > user-friendly than "cardinality". > > And are you arguing that we should do this, or only that we could? could.... -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Thursday, 21 June 2007 23:08:44 UTC