RE: [xml-dev] Are people really using Identity constraints specif ied in XML schema?

[w3c@drrw.info]

Len,

Ok - now you have drifted over into my other "baby" - the world of BCM -
Business-Centric Methodology.

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
this solved!

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.

Cheers, DW

=========================================================================
Quoting "Bullard, Claude L (Len)" <len.bullard@intergraph.com>:

> 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>
> > 
> > 
> 
> 
> -----------------------------------------------------------------
> 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>
> 
>