OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC