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

[Jeff Lowery <jlowery@scenicsoft.com>]

> Validate a field on input?  So I load a really big schema to validate 
> a field on losing focus?  

No. There's more than one way to skin a Schema. Code gen the schema
constriants into classes whose mutator methods will do the checking for you.
That's one way. Or translate the constraints into something that can be
stored in a lookup table by xpath or qualified name. It can be done... I'm
sure you're more clever than I am... I can do it, so you can do it better.


> IOW, performance still counts.

Yep, but not so much at compile time.

> 
> Yes, centralization and diversity can be at odds. But any 
> one out here that is building custom one off apps is in a 
> different business from those of us who build complex 
> agency applications.   Sure, there can be a set of data 
> rules and we have those down cold in our market.  But 
> each agency and each state and each country gets to 
> futz with them (real problems with m12n).  We never quite 
> get into the turnkey game supporting enterprise data. 
> It sounds like a good idea, but doesn't pan out.   

Yeah. I'm with ya.

> One can seek to keep onsite implementation and 
> customization costs from making a tier 2 system cost 
> like a tier 1 system and stay out of the tier 3 systems 
> altogether.  We scale technology to the market not the 
> other way around.  XML is supposed to help us do that 
> but XML still requires a force of standardization, so 
> those who think the w3c should be turned into a group 
> of anti-standard heads probably isn't in the tier 1 or 
> 2 marketplace.

There's standards, and then there's workable standards. And then there's
standards that can be extensible. Trying to be all things to everybody,
leads either to watered-down functionality (namespaces, for some people) or
overburdening complexity (XML Schemas, for some people). Time to admit that
we've got two different user groups (perhaps more) that can't be pleased by
these types of solutions. We can find common ground, of course. I'm not
anti-standards, but multi-standards. The doc-heads and data-heads really see
the world very differently, and yes, sometimes they do need to exchange
information. Doesn't mean that there's a common world view, however, just
some overlap.

> 
> As one who reads a lot of RFPs, the only group I'd like 
> to nail to the masthead is the proposal consultant who 
> actually never had to build a system, or hasn't 
> built one for twenty five years, or built the 
> last one as a web application and doesn't understand 
> the problems of non-Intenet mission critical apps 
> that may or may not have web interfaces.

Yeah, well, I'm sure they're only trying to help. What was that about
listening to crappy guitarists you where saying?


> 
> Len 
> http://www.mp3.com/LenBullard
> 
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
> 
> 
> -----Original Message-----
> From: Jeff Lowery [mailto:jlowery@scenicsoft.com]
> 
> 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.
>