[
Lists Home |
Date Index |
Thread Index
]
while i already have a stated position on the dangers of overly strict
checking systems - i like to see easy to spot errors so i can get a
measure of how many hard to see errors are in the system - i do think
there is a very important and valid role for it systems to implement and
enforce business rules.
while this is not necessarily the same as constraint checking - indeed
it can be much more complex - it is something that makes our systems
more than just data/document repositories and number crunchers.
i have any number of examples of where there has been a supposed system
failure, only to find on investigation it has been a breaking of the
business rules and the it system is the warning system to management
that something needs to be investigated.
rick
Bullard, Claude L (Len) wrote:
>Michael is right, but this isn't a one size fits all decision.
>Loose filters allow dirt to seep into the system. The architectural
>question is what are the right places to put such rules into
>a system? We are aware of different technologies for this,
>and it is a good thread to out the issues if that interests
>the members of this list.
>
>That a technology can accomplish a task doesn't mean it
>is the right tech for that task. It doesn't mean it isn't.
>I suspect this is another task situatedness issue, but given
>a services architecture, one might want to inquire about
>tasks relative to their roles in distributed processes
>that are candidates for orchestration.
>
>len
>
>
>From: Roger L. Costello [mailto:costello@mitre.org]
>
>Michael Kay wrote:
>
>
>
>>I tend to be a little wary of constraints myself.
>>Many of those you see in student textbooks are
>>misguided. If I see a schema (XML or RDB) with the
>>constraint that employees must be over 16, I ask
>>myself what the IT department would do if the
>>business decided to hire someone under 16. If
>>there's a rule that an employee's manager must
>>themselves be an employee, I ask what would
>>happen when someone is told that they now report
>>to a contractor.
>>
>>
>
>This is excellent:
>
>
>
>>It's not the job of computers to limit what people
>>are allowed to do (or the job of the IT department
>>to regulate the business).
>>
>>
>
>The following innocuous sentence has profound implications
>on the role of schemas:
>
>
>
>>A guideline I use is that constraints should be there
>>only to protect the IT system itself from data that
>>it cannot handle.
>>
>>
>
>Would you elaborate upon this sentence Michael? I believe
>that you are saying that the role of a schema is to define
>things such as:
>- ensure that a "date" is indeed a valid date
>- ensure that an "age" is indeed a valid age
>
>The role of a schema is not, for example, to specify:
>- the "age" must be at least 16.
>
>So, your guideline says: use schemas to specify datatypes
>for objects, not their range of values. Is that a fair
>summary of your guideline? /Roger
>
>
>-----------------------------------------------------------------
>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>
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
