[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Issue 11. MNrepeat: Repeat M-N times
Message text written by Josh Lubell > 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< >>>>>>>>>>>>>>>>>>>>>>>>>>> Josh, These problems arise mostly because people in their own world view do not foresee any problem with the constraint! Some of the examples you noted where like this - i.e. document signature requires two signatures. Ok - but now my applications need three signatures - sorry - you cannot do that! I'm not proposing we completely disallow constaints - just make it so that people are fully cognisant of WHAT they are doing, and also, that as with ebXML approach, this is explicitly a business partner-centric limit, so that someone else is not hog-tied by that version, but can sub-version around it. Sure if I'm sending trading partner X a signed form, it only has two signatures on it, as his LIMIT is 2, but everyone else does not see that limit. OCCURS="*" LIMIT="2" does this nicely. I can see the one to many, and I also see that this guy can only handle 2. This is why the registry is so vital a piece, because once you start asking business questions, who is the first signature? who is the second? who is the third? and so on, then you need the semantic registry to tell you. I'm just very focused on keeping the schema to simple structural layer metadata, and enabling business processes built using those information containers - not inhibiting them with potentially unsolvable content issues - which is where EDI went wrong - too locked in stone. Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC