[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue 11. MNrepeat: Repeat M-N times
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC