Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Are people really using Identity constraints specif ied i
 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@i...>: > 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@d... [mailto:w3c@d...] > Sent: Thursday, August 19, 2004 1:35 PM > To: Bullard, Claude L (Len) > Cc: 'Roger L. Costello'; xml-dev@l... > Subject: RE: 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@i...>: > > > 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@m...] > > > > 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> > > 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
