OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Are people really using Identity constraints specif ied in

[ Lists Home | Date Index | Thread Index ]

From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]

Bullard, Claude L (Len) <len.bullard@intergraph.com> 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




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS