[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ZDNet Schema article,and hiding complexity within user-friendlyproducts
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Gavin Thomas Nicol <email@example.com>, xml-dev <firstname.lastname@example.org>
- Date: Tue, 24 Apr 2001 14:08:24 -0500
Not every pipeline, but where one uses it
in the pipeline is important. Take the
famous co-occurrence constraint, aka, correlation.
Should I correlate in the GUI (eg, a pattern
check validation using script), on send,
or on receipt? Any or all will work but
the last requires the most network traffic
and possibly incovenience given a context
where everything needed is at the client
already (say, form field validation).
Business objects may be different. In this
case, I need to correlate the data entry to
server-side information. If I get a blind
transaction from a trading partner, I may want
to correlate the entire input. Now the
schema looks good but only insofar as the
message received is atomic.
So the context of a context, that is, where
am I in the pipeline and what do I need
from the context to validate the entry
makes a world of difference. This may
be at the root of some of the XML Schema
despair; trying to make it affective over
all potential process contexts rather than
a few or one. Schemas are usually cheaper
they aren't parameterizable unless I put
XSLT in the pipeline too. Now I am into
self-modifying code and my nausea quotient
Intergraph Public Safety
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Gavin Thomas Nicol [mailto:email@example.com]
Ahhh, but how will you use it? The assumption I've seen
people make it that it'll be part of every pipeline.
I may/probably will use XSchemas to validate
the correctness of my application. I most likely
will not use XSchemas to validate my content (except
in some very specific domains).