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: Repeat M-N times


At the moment, TREX provides elements to

- repeat 0 or more times (zeroOrMore)
- repeat 1 or more times (oneOrMore)
- repeat 0 or 1 times (optional)

There are other logical possibilities:

- repeat N or more times, where N > 1
- repeat between 0 and N times, where N > 1
- repeat between 1 and N times, where N > 1
- repeat exactly N times, where N > 1
- repeat between M and N times, where 1 < M < N

Obviously, all of these can be reconstructed from the primitives that
TREX provides.  However, they would be inconvenient especially as N gets
large.  So if any of these other possibilities are common, we should
consider providing some support for them.

So the question is: which if any of these other possibilities arise
commonly enough that it is worth providing an additional pattern in TREX
to make them convenient?

Personally, I have never found a need for any of them, but my experience
is more in documents than data, and it is possible that there may be
data domains where these are common.  However, I don't think we should
add features to TREX just on the basis that it *might* be useful to
somebody. Maybe somebody could look at some W3C XML Schemas for data,
and see what cases come up.

If we do add support any of these, then we have the issue of what if any
limits we place on the values of M and N, and what if any are the
minimum values of M and N that conforming processors are required to
support.  I can just imagine somebody writing a schema for input to an
database, the database has a limit of 2^64 objects, so instead of using 
<zeroOrMore>, they use <repeat min="0" max="18446744073709551615">. This
seems slightly less of a problem for the exactly N times and the repeat
N or more times (ie the cases where N is a lower limit rather than an
upper limit).

It will be hard to avoid interoperability problems here.

James




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


Powered by eList eXpress LLC