[
Lists Home |
Date Index |
Thread Index
]
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@ntlworld.com>:
> > 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>
>
>
|
