[
Lists Home |
Date Index |
Thread Index
]
Because the schema is easy to build and quick to change
in a local environment. If it is all optional, that's
fine as long as it recognizes the options. It is just
a means. The question is, is it the right means for
a situated task (yes, context is the determinant).
Context is a boundary.
The issue of scalability is that a schema declares a test
for a boundary of an information ecosystem. One can be
within it (cenospecies), adjacent(ecotypes), overlapping (ecospecies)
or isolated (ecosystem). The degree of stability (the
correlation coefficient) changes within some measure of
time and isolation given a dynamic ecosystem.
Dynamism creates complexity. The origins of complexity are
the number of concurrent relationships among ecotypes,
the behaviors that result from traversal or activation
of relationships, and the number and individual complexity
of interacting instances of ecotypes.
Because this occurs within an energy-constrained
environment (energy budget), means (eg CAM) are
selected by the owner or meta-agent (you and me
or some future bot), to meet goals for these ecosystems
both tasks (why do we use software) and performance
(what means do we use).
So to me, CAM is a means, not a fundamental objective.
What we should discover here is if there is a fundamental
objective that CAM can be the means to attain, and compare
it to other means.
Evolution is not only adaptive. It is generative.
len
-----Original Message-----
From: w3c@drrw.info [mailto:w3c@drrw.info]
Sent: Thursday, August 19, 2004 1:35 PM
To: Bullard, Claude L (Len)
Cc: 'Roger L. Costello'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Are people really using Identity constraints
specif ied in XML schema?
Len,
Why have the schema muck with this stuff at all?
If you are going to have to use another layer to do the
validation - why separate out part of it and delegate
it elsewhere?
And especially if you create registries of definitions
that are referenced by the transactions - then it becomes
moot - since the registry provides you the ability to
manage the rules and propagate changes. That's the rub.
Hard wiring in local contraints usually comes back to
haunt you - even if you think what you are hardwiring is
unlikely to ever change....
Cheers, DW
=============================================================
Quoting "Bullard, Claude L (Len)" <len.bullard@intergraph.com>:
> John Sowa posted the following to the CG list.
> Not surprisingly, I disagree with the conclusion
> in this situation, but I do agree with the
> rest of the text:
>
> "The basic point of the paper is the following
> restriction: "all quantifications are bounded
> by some variables". This kind of restriction
> is very common for most practical applications.
>
> For database queries and constraints, an even
> stronger restriction holds: every quantifier is
> bounded by a *constant*, namely the cardinality
> (number of rows) of the corresponding table.
>
> In natural languages, it is extremely rare to
> find any sentence with an unrestricted quantifier.
> Even when the word "everything" is used, some
> implicit domain is almost always intended.
> Furthermore, those domains are almost always
> finite. (The major exceptions are books, papers,
> and courses on mathematics.)
>
> In logic, a noun phrase such as "every employee"
> maps to a typed, sorted, or restricted quantifier
> of the form (Ax:Employee). Those quantifiers
> usually have a constant upper bound, although
> that bound may be very large for the domains
> of people, bacteria, or web pages.
>
> This means that for most practical applications,
> theories stated in first-order logic with restricted
> quantifiers are decidable. However, the domains
> might be so large that even a polynomial amount
> of time is beyond the age of the universe.
>
> Bottom line: The most important issue is
> scalability, not decidability."
>
>
> From: Roger L. Costello [mailto:costello@mitre.org]
>
> 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>
>
>
|
