[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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. ========================================================== 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. <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC