- From: Innovimax SARL <innovimax@gmail.com>
- Date: Thu, 21 Jun 2007 09:43:14 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
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 ? for 1-or-more, I agree that's a bit of sequence where you mandate a content, and I also don't catch a serious use case > > But we don't have any atomic steps which need the missing options, so > we're considering a change that would only be used by some future (or > extension) atomic steps or by pipeline authors. > > For pipeline authors, it seems that you'd have to handle the > optionality anyway, so handling the case of more than 1 when you > expected 0 or 1 wouldn't be a burden. > > Absent more compelling arguments for changing the status quo, I don't > think any change is likely to be made. > > If we do make a change, there was clear sympathy for a position which > says that neither of the two existing cases should be made more > difficult. That is, exactly 1 should be the default and 0-or-more > should require at most one attribute. > > 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 -- 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 07:43:22 UTC