RE: ZDNet Schema article,and hiding complexity within user-friendlyproducts

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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 
than equivalent JavaScript; on the other hand, 
they aren't parameterizable unless I put 
XSLT in the pipeline too.  Now I am into 
self-modifying code and my nausea quotient 
goes up.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Gavin Thomas Nicol [mailto:gtn@ebt.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).