When To Use Schemas (Was RE: infinite depth to namespaces)
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. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Jeff Lowery [mailto:jlowery@s...] Sent: Thursday, August 30, 2001 8:29 PM To: 'Simon St.Laurent' Cc: xml-dev@l... Subject: RE: infinite depth to namespaces Simon sez: > 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... -- Jeff ----------------------------------------------------------------- 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 manager: <http://lists.xml.org/ob/adm.pl>
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