[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [relax-ng] Re: MinOccurs in RELAX
I don't understand the difference between a "LIMIT constraint" and min/maxOccurs. Can you give an example of how this would be used with the zeroOrMore/oneOrMore elements that we have now? ----- Original Message ----- From: "David RR Webber - XMLGlobal" <Gnosis_@compuserve.com> To: "Martin Bryan" <mtbryan@sgml.u-net.com>; "RNG List" <relax-ng@lists.oasis-open.org> Sent: Monday, October 15, 2001 11:54 AM Subject: [relax-ng] Re: MinOccurs in RELAX Message text written by "Martin Bryan" > Absolutely. There are a number of cases where it just does not make sense to have singletons, and you need a minimum. The examples I gave in the case studies is the classic one. My bookclub only allows me to renew membership if I order 4 books at the same time. When it does special offers I am not allowed to ask for more than 3 of them at a time. These are real worlds restrictions. <<<<<<<<<<<<<< Martin, I concur here. I see that what we need is a LIMIT constraint. The advantages of this is that our existing min/maxOccurs is not disrupted - and then if someone does want to set a LIMIT they can do - and it is then abundantly clear what is going on. I never liked the W3C schema approach as EVERY occurs statement was an exception! This way - we know explicitly when a LIMIT assertion is made. This means you encourage use of no limits as normal - and this maximizes interoperable information exchanges - while still allowing constraints when the business case requires. James - does it sound reasonable to add a 'limit' option to min/maxOccurs here? Thanks, DW. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC