Lists Home |
Date Index |
Ok - now you have drifted over into my other "baby" - the world of BCM -
Paraphrasing your comments - it boils down to this - time and time and time
again I hear people saying - but all I need is a schema and then we can get
Whoever started this nonsense thinking? Can we drag him or her outside and
shoot them or something?
Whenever I hear this I always ask - 'OK - can we start by understanding and
deciding on the business problem we are trying to solve first?'. Once I know
that - then I have a better idea what information I might need - and then I can
figure out how to get it. 'No no - I hear - we don't need to do that - we just
need to define a schema.
And what are people going to do with the schema, and how are you going to convey
to them in a concise manner, the information you want put into it?
Hint: answer might start with C and end with M - once you have gone thru the
analysis that the BCM teaches you should be done.
Oh well. Meanwhile people are so excited when they create a schema.
Quoting "Bullard, Claude L (Len)" <firstname.lastname@example.org>:
> 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.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]
> Sent: Thursday, August 19, 2004 1:35 PM
> To: Bullard, Claude L (Len)
> Cc: 'Roger L. Costello'; email@example.com
> Subject: RE: [xml-dev] Are people really using Identity constraints
> specif ied in XML schema?
> 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)" <firstname.lastname@example.org>:
> > 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:email@example.com]
> > 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>