- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 23 May 2007 14:05:43 +0100
- To: public-xml-processing-model-wg@w3.org
Norman Walsh wrote: > I see the trade off this way: > > With the status quo: sequence=yes means zero-or-more, no means 1. That > means that when you want to allow zero-or-one, you have to specify a > sequence even though that's not exactly what you mean. > > If we add new options to support 0-or-1, 1, 0-or-more, 1-or-more then > you get finer control for the use cases where you want it. But it > also means that we have to explain this variety of options, introduce > markup for it, and implementations have to test for dynamic errors > against all these options. > > On balance, I'm not sure the added complexity of supporting four options > is justified by the added functionality. > > I don't feel strongly, but it's not obviously worth it to me. I understand you want to keep it simple, but the status quo seems weird to me. Like many XML users, I'm used to using ?, * and + to mean zero-or-one, zero-or-more and one-or-more, and having that full range of possibilities. Being restricted to just exactly-one and zero-or-more seems very strange in that context, and requires more explaining than supporting the full range would. After all, in the current state of affairs implementations are going to have to implement both isThereADocument() and isThereMoreThanOneDocument() checks to support sequence="no", and if you've got those two checks then it's not much effort to test each of them individually to give support for zero-or-one and one-or-more. And not doing this small amount of extra speccing means that users are going to have to do tedious bits of p:counting to test whether their sequences have a maximum of one document in them. I don't want to do anything too major (like saying that you don't have to bind to optional inputs at all). I think that doing cardinality="one", cardinality="zero-or-one", cardinality="zero-or-more" and cardinality="one-or-more" is the right amount of laziness here. > Indeed the binding issue is tricky. Our defaulting story for inputs > means that it's almost always the case that an input not explicitly > bound gets implicitly bound somewhere. So I think if you want an unbound > input we either have to provide new markup or you have to explicitly > bind it to an empty sequence: > > <p:input port="source"><p:inline/></p:input> I think you mean: <p:input port="source" /> to bind to the empty sequence. Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Wednesday, 23 May 2007 13:10:56 UTC