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

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

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.