[
Lists Home |
Date Index |
Thread Index
]
[Rich Salz]
To: "Thomas B. Passin" <tpassin@comcast.net>
> > 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 suck."
>
> 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
|
