[
Lists Home |
Date Index |
Thread Index
]
The other alternative is to have such data configuration-driven. Use some
kind of properties file to specify things like minimum age, and reload,
which is more or less what you would have to do in a schema anyway.
In fact, I think that's the salient point. Whether you do it via schema or
in a properties file that controls application behavior, the critical factor
is to make software updates declarative in nature as much as possible-
basically, make them configurable, either via schema (just a specialized
config file?) or via properties. The advantage to using schema to do it is
you can introduce new constraints without affecting the code, although that
may be an oversimplification since you may want behavior to change (content
of error messages should the validation fail, alternate processing in the
event of certain kinds of errors)along with the schema.
Linda
-----Original Message-----
From: Owen Walcher [mailto:xpriori@owenwalcher.com]
Sent: Thursday, August 19, 2004 10:43 AM
To: Roger L. Costello; xml-dev@lists.xml.org
Subject: Re: [xml-dev] Are people really using Identity constraints
specified in XML schema?
If I am in charge of managing the applications for this company, I would
rather make a change to a schema than to have to open up source, modify
variables, and then recompile just to enforce an age of 18, say, instead of
16.
I can make this change in one place (the XSD), and the next XML document
that comes in gets the new enforcement rule... seems like, from a developer
point of view, you would want to do as much as possible in the schema,
leaving the complex logic to the application (like we only process sub-par
loans on the third Wednesday of the month) that cannot easily be done in
Schema.
Owen
----- Original Message -----
From: "Roger L. Costello" <costello@mitre.org>
To: <xml-dev@lists.xml.org>
Sent: Thursday, August 19, 2004 10:15 AM
Subject: RE: [xml-dev] Are people really using Identity constraints
specified in XML schema?
> Hi Folks,
>
> Here are some thoughts:
>
> 1. Constraints on data are not equal to business rules.
>
> 2. Business rules change. Constraints on data do not.
>
> 3. Constraints on data should be specified in XML Schemas. Business
> rules should not. Business rules should be specified in higher level
application
> code.
>
> Example:
>
> A company has employees. The current company policy on the minimum
> age requirement is 16. Should the company create an XML Schema that
constrains
> <minimum-age> to 16? Or, should the company create an XML Schema that
> simply constrains <minimum-age> to an integer, and let applications
> higher up provide further constraints?
>
> Answers:
>
> - Mandating that the minimum age of an employee be 16 is a business
> rule. It is highly likely to change over time.
>
> - The value of the <minimum-age> must be an integer. This is a
> constraint on the data. It will not change over time.
>
> Therefore, an XML Schema should simply constrain <minimum-age> to be
> an integer. Higher level applications should implement the business
> rule
that
> <minimum-age> be further constrained to 16.
>
> Comments?
>
> How would you characterize the distinction between "business rules"
> and "constraints on data"? /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>
>
-----------------------------------------------------------------
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>
|
