[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
When To Use Schemas (Was RE: infinite depth to namespaces)
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Jeff Lowery <email@example.com>,"'Simon St.Laurent'" <firstname.lastname@example.org>
- Date: Fri, 31 Aug 2001 08:40:54 -0500
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.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Jeff Lowery [mailto:email@example.com]
Sent: Thursday, August 30, 2001 8:29 PM
To: 'Simon St.Laurent'
Subject: RE: infinite depth to namespaces
> 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...
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