Lists Home |
Date Index |
You only *think* that's what you can do. Schema tends to be
a localizing technology - so odds are - you have to chase
down all possible users that may have old copies...
Compare this to an XML templating approach that uses registry
as the semantic store. Now every template that references
those definitions will get the new one next time it is invoked.
Of TBL (Tim Bernes-Lee) does like this approach because he
worries about single points of failure... however registry
these days is a federated model - so content can be drawn
thru different paths and cached as needed. The DNS itself
of course is an example of such distributed referenced
However - overall - I see compiling code is a bad way to
make changes. The promise of XML is the ability to have
agile systems that self-configure based off XML rules sets.
This is the real promise behind technology like OASIS CAM
templates and definately the environment change we are
seeking to empower.
Quoting Owen Walcher <email@example.com>:
> 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
> 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
> ----- Original Message -----
> From: "Roger L. Costello" <firstname.lastname@example.org>
> To: <email@example.com>
> 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
> > 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
> > <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
> > <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>