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

[Josh Lubell <lubell@cme.nist.gov>]

David,

Unless I'm missing something, it seems to me that your concern about
minOccurs and maxOccurs is that they encourage developers to hard-code
cardinality constraints in their schemas. I agree with you that this is bad
when the cardinality constraints are arbitrary. However, I think this is
good when the cardinality constraints reflect physical reality (e.g. a
polygon has 3 or more verticies) or universally agreed-upon conventions
(e.g. a week has 7 days).

The Y2K problem was caused by programmers who built systems with hard-coded
constraints reflecting implementation considerations rather than any
commonly-held world view *and neglected to be explicit about it*. Perhaps
the lesson to be learned here is that constraints due to implementation
considerations should be separated from constraints implied by physical or
social reality.

I don't think XML schema languages should forbid cardinality or min/max
constraints just because sloppy developers *might* use them inappropriately.

Regards,
Josh

----- Original Message -----
From: "David RR Webber" <Gnosis_@compuserve.com>
To: "Josh Lubell" <lubell@cme.nist.gov>
Cc: "TREX Discussion List" <trex@lists.oasis-open.org>
Sent: Tuesday, May 01, 2001 11:35 AM
Subject: RE: Issue 11. MNrepeat: Repeat M-N times


> 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.