RE: Are people really using Identity constraints specif ied in
From: Hunsberger, Peter [mailto:Peter.Hunsberger@S...] Bullard, Claude L (Len) <len.bullard@i...> writes: >> Let's ask the question another way. Considering that a schema >> only knows how to do one thing, test conformance of an instance >> to itself, where should a schema sit in a model-view-controller >> architecture? >Cheap shot: as far away as possible.... So I would have thought. As I read further, I discovered that MVC is a scaling pattern. Different parts of an architecture have different models; thus as in the message that followed, one finds a schema validation step taking place in what I would have considered interprocess communication, eg, the handlers. My two most fundamental errors are to consider schemas only at the external system junctions and to consider only a single schema. (I do know this is wrong but it is a thought habit.) >> A user interface is likely doing all of the following: >> >> 1 Managing the flow of information through the user interface components >> 6 Accumulating data taken from many UI components to perform a batch >>update at the server >>> 7 Keeping track of the progress of a task in a user interface process" >I find MVC to be an incomplete model, but playing along with this for a >moment, what about 1? Early validation that what the user entered is >what the application expects is always good? Is it? It might mean I couple the validation to the user interface and it is coupled to the device. That might not be the best place to put the schema. A question is which events cause a validation? Do I validate all form entries at one time (on submit) or validate each field as entered (on loss of focus, on tab, etc.). Obviously the latter fattens up the client and forces me to replicate some rules across clients and devices. Also, given the MS configuration file, some of this validation is for the file itself because in that system, transition declarations are pushed out of the UI presentation file itself. So I am wrong in the next statement. >> Would I want to use the schema to find exceptions that modify user process flow given this also >>affects transition management? Likely not. Again, I fall into the trap of thinking of THE schema and not recognizing the system as a declarative ecosystem of schemas and schema components. >>Verify that data taken from many components are valid prior to performing a batch >>update? Ok. That looks like a good candidate. But is it? Yes. >Well, if you're trying to protect the back end from bad data (assuming >it can't protect itself) then it seems like another good spot. It is one of many schemas one might be using. So far, the idea that the schema is a 'train wreck' seems to be false. However, relying on one monolithic schema for all tasks is. Now we have a version management issue. >Given the current state of the Web I've come to assume that the ideal >architecture would do duplicate validation. Possibly. That is the Trust But Verify approach. The looser the coupling, the more fit that approach becomes. Loose coupling weakens reliance on correct-by-construction techniques. Otherwise I suspect we apply XML at some scales of the system because we can. len
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format