Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Are people really using Identity constraints specified in
 Michael, Business contracts are best handled with ebXML BPSS and CPA - that reference the documents, XSD and CAM templates IMHO. Take your newsfeed example - (BTW date checking is gnarly - especially around midnight boundary). So you have a CAM template checking the news_date field to todays_date (system value). What if the feed supplier has a system glitch yesterday - and now he's playing catch-up with yesterdays news items? Hmmm. A BPSS could help you out of the hole - by providing a context parameter 'news day' and then having a time-to-complete criteria - of say 48 hours, with a payment penalty for > 24 hours. Now the transactions come with a news_day value - and that makes everything smooth - no need to check system_date (with all the problems that brings of time_zone / time synchronization / hell). So - lessons learned - schemas are dumb - knowing context is vital - using context variables gets you a more robust real-world system design - using BPM tools to manage state is even better. Cheers, DW. Quoting Michael Kay <michael.h.kay@n...>: > > Michael, your messages and examples are precise and compelling. > > Would you mind elaborating more upon what you see as > > the role of validation? > > I see two main roles for validation: > > (a) to protect the system from data that it cannot handle. If the system can > only handle 7 values for the "colour" attribute of a car, then it should > validate incoming data to check that it has one of those 7 values. It would > be better to design the system to handle more colours, but if you can't > afford to do that, then you must check that the incoming data fits within > the design limits of your system. > > (b) to enforce a contract. If you have a contract with the supplier of a > news feed that all articles sent will carry either today's or yesterday's > date, then you should check that your supplier is keeping to the contract. > (You need to be very clear about what you plan to do when validation fails.) > > There is also scope for reasonableness checks to catch data input errors. > But they belong as close to the user interface level as possible, not at the > information management level. > > > Should there be levels of validation as I suggested last week? > > In the sense that there are always layers of protocol, then yes. XML > well-formedness and validity checking can be seen as two such levels. > > I think there is also room for validation processes that check data to see > if it conforms to business rules. But very often, that should result in some > kind of exception reporting, rather than rejection of the data. Often it > will be correct, valid data, revealing that the business rules have indeed > been breached. > > Michael Kay > > > ----------------------------------------------------------------- > 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 list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > > 
|
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
|
|||||||||
