RE: Issue 11. MNrepeat: Repeat M-N times

[David RR Webber <Gnosis_@compuserve.com>]

Josh,

OK - time for me to present the opposite view.

I have consistently argued that Min/Max is a DISASTER from the 
point of view of interoperable business processes - of the order 
of magnitude of the Y2K problem that cost BILLIONS of dollars
worldwide (the last real world example of a min/max constraint).

LET US NOT REPEAT this glaring blunder.  Just because people
are out there HARDCODING fixed constraints into their schema
implementations does not mean we should endorsing or condoning
this.

In fact if they CANNOT find a way to hard code in constraints - we are
doing them a major favour.  We mostly certainly do not want this as
the DEFAULT behaviour, a la W3C schema!

The ebXML Registry model based off UID references from the schema
is the way to go.  If people really, really, really need some support for
backend legacy hard coded constraints, then they can put these as
trading partner limits in the registry reference to their business 
implementation details.

I argued this case in the schema WG - but they have this limited
world view that does not include the trading partner model that 
ebXML provides - so they had to go with hardcoded MIN/MAX 
because they had nowhere else to put this stuff (and a shed load
of other baggage and complexity as well of course).

We can do better.   At the time I urged the use of 
OCCURS=[*,?,{instance}] as the only modelling method, and then
having an optional LIMIT qualifier if you absolutely had to hardcode
an upper limit.  Notice this has the side-benefit of making it 
extremely easy for agent software to diagnose a schema and
alert to any use of the LIMIT - otherwise all one-to-many and 
many-to-many relations are not constrained.  

Easy, simple and obvious.

Thanks, DW.

==========================================================

Message text written by Josh Lubell
> 
During the April 19 teleconference I took on an action item to find
additional evidence of the popularity of min/max constraints in existing
XML schemas. Here are some real-world examples, all of which use minOccurs
and/or maxOccurs to represent cardinality constraints. I'm sure I could
find more if the TC is still unconvinced that min/max would be a good idea
for TREX version 1.

1. Geography Markup Language
http://www.ned.dem.csiro.au/XMML/gml2/
A LinearRing is defined by four or more coordinate tuples.

2. Extensible Provisioning Protocol Domain Name Mapping (IETF Internet
Draft)
http://search.ietf.org/internet-drafts/draft-hollenbeck-epp-domain-01.txt
An EPP <update> command (whatever the heck *that* is) can contain up to 8
add/remove elements.

3. flightSchedule schema from Virgin Atlantic Airways
http://www.biztalk.org/library/view_object_details.asp?id=542 (you have to
request a BizTalk userid and password to read this URL)
Flight instances have from 1 to 7 days of operation

I also found some examples with maxOccurs equal to 2. Although the need for
min/max for the following is less compelling than for examples 1 through 3,
I still think there would be some benefit.

<