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

["Bullard, Claude L (Len)" <clbullar@ingr.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.  If 
the business logic goes back to the server, in theory, 
we have it all in one place and that is easier to work with. 
On the other other hand, it is nice to validate a certain 
amount of that before submission particularly in occasionally 
connected systems that control workflow, prepare reports, 
try to optimize downtime effort, etc.  For that, a strong 
schema with say Schematron assertions looks promising.
 
Tim pointed out the issue:  how much and what kind to 
do with the schema and what to do with the scripting 
logic.  For example, when should regexes be called 
from a script (common ASP practice) and when should 
the schema be used.  A simple case would be tabbing out 
of a field and using the lost focus event to trigger a 
field validation.  That obviously goes to the script 
calling a specific function given the schema is overkill 
if it is very comprehensive.  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.

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

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]
Sent: Thursday, August 30, 2001 8:29 PM
To: 'Simon St.Laurent'
Cc: xml-dev@lists.xml.org
Subject: RE: infinite depth to namespaces


Simon sez:
> Should be a beautiful world for some folks, but I don't think that
> normative syntax is going to help too awfully much with keeping the
> Infoset folks from painting XML into something far grander 
> than syntax.
> The developers writing the business logic are eventually going to get
> aggravated about writing code that duplicated previous checks, and I
> suspect they'll respond by insisting that schemas start 
> supporting more
> business logic.  (That's been happening for a while, it seems.)

I think even database afficionados would argue for the separation of
volatile "business logic" (which directs the processing of data) from the
more stolid type constraints that schemas provide. Admittedly, the line is a
little fuzzy, but it's there.

In databases, triggers and stored procedures have there place, but people
soon found out that pernicious centralized process control caused all sorts
of problems when requirements changed or diverged. What I think you'll soon
see is a desire to standardize the loose coupling of schema constraints with
business logic, such as adding protocols to appInfo annotations. Perhaps not
a pretty or even good solution, but a makeshift one that will do for awhile.
Cleaner couplings would have litte, if any, impact on XML (one would hope).

In the end, I think XML and XML types will be isolated in the data layer
along with semi-automated storage mechansisms. On top of that would be glue
code for loosely couple business logic, which in turn has application logic
resting on top of that. That's a little utopian but grossly represents how
data-intensive systems are architected now.

You document people will get along just fine without worrying your pretty
little heads about all that...

-- Jeff

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.xml.org/ob/adm.pl>