Cart
[Home] [By Thread] [By Date] [Recent Entries]
[Rich Salz] To: "Thomas B. Passin" <tpassin@c...> > > Even in a case like that, somewhere you or software would have to decide > > what to do in case there were more records than the form could hold. That > > cannot be done with the information in the schema anyway. So why bother > > putting the constraint into the schema in the first case? It doesn't really > > solve the problem it is there to handle. > > I am in awe of the hubris of folks who can make such generalizations. > Wow, finally someone in awe of me ... Thanks, Rich :-) But, you know, what I wrote was more along the lines of wandering along memories of past experience than trying to lay down the law. Also, in the past year I have been involved with the development of some schemas where minOccurs and maxOccurs were used. So far I have not seen any real benefits to their use - well, except for 0 and 1 values that is - for our case. Where they were used, I do not think it will matter that much if they were not available. I used to think that being able to apply this degree of control is a good thing. I am not against it now. I just think there are not many practical cases where the lack of the ability would have much practical impact. Of course, the world is large and and there is a place for everything. Now business rules are another story, I am not talking about that. > "Trust me, if you try to strictly define your data, then your software > will [expletive deleted]." > > Wow. > No, it is more about accepting generously and sending rigorously. Maybe that is part of the difference in viewpoint. I am thinking mostly about being at the receiving end. > Perhaps folks really mean "this is the final straw, making XSD so > complex that as validation-implementors we cannot stand for it." > But that is not what they've been saying. I did not mean that at all (even though most days I think it is too complicated). Cheers, Tom P
|
