RE: When To Use Schemas (Was RE: infinite depth to namespaces)

[Jeff Lowery <jlowery@scenicsoft.com>]

> That problem is already here.  How much validation should 
> a client do and how much should be passed off to the 
> server business logic?  With fat two tier, a lot of business 
> logic is spread around the programs and in many development 
> organizations, that is hard to maintain and manage.  

Yes, but centralized rules are like centralized economies. There's no one
right way of enforcing business rules, but there are solutions that offer
the best trade-off between flexibility and managability. See my other post
"Tragedy of the commons", which argues for 1) recognition that XML
encompasses more problem domains than it can chew, 2) that proper layering
of common and specialized concerns might just allow us the ability to
interchange documents and data without dictating to one another. 

Each division and department in a company has it's ways of doing things, but
core processes must exist along with specialized processes that meet unique
requirements. There's a constant push to conformity from above at the same
time there's a pull to autonomy from below. It's a pattern that we see in
politics. Does one have a tyranny, republic, or federation? 

The tricky part is the management of divergent concerns. Pretending that you
can meet all concerns with one set of rules is not going to get one very
far.

> Because a form is usually 
> is a subset of all of the database fields, I can group 
> all the validations into a single onSubmit function. 
> So far, I don't need the schema.

Get your schema to enforce rules on your input fields. Multi-purpose it. 

> 
> So when do I need it?  Obviously, it is a nice contract.

And enforceable in a variety of ways. There's still the extra stuff that's
not handled by the schema, but the schema can be loosely bound to what is
extra.