[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: A standard approach to glueing together reusableXMLfragme

codd s 12 rules
<quote>Yes, Codd's 12 rules are reasonably objective as these things go.
> trouble is, when you try to use them, they tell you that every real
> system is not relational, which isn't very helpful.

why do we always say 12 rules? like all good mathematicians codd counted
from 0. [0,12] is 13 numbers or rules in this case.

and while i'm on it, there's 5 normal forms. 3rd is easy to get to, but
5th is by a country mile better for storage and manipulation.



> On Tue, 2003-08-26 at 05:11, Michael Kay wrote:
> > 
> > I am saying I have not seen a proof that XML supports, or can 
> > be engineered to support, the Relational Model.
> Of course XML doesn't support the relational model. The relational model
> consists of structures and operations on those structures; XML doesn't
> define any operations on its structures.
> And what does "support" mean anyway? What does it mean to "support" a
> model?
> > 
> > 1) One reason the Relational Model was developed was to 
> > reduce coding and design efforts required throughout the 
> > application life cycle, while offering as much flexibility 
> > and reliability as possible.
> You're guessing. At any rate, that's not how Codd described his goals in
> his 1970 paper.
> > 2) Data based applications developed using the Relational 
> > Model, which are well engineered and designed, will feature 
> > lower cost over time with greater flexibility. 
> Evidence please? (Lower than what, anyway? Lower than badly engineered
> and designed systems?)
> > One rule of 
> > thumb is that maintenance costs will be less than 1/100th of 
> > the development (or all pre-production costs).
> Are you serious? You are telling me that a system that costs $10m to
> develop will have a lifetime maintenance cost of $100K?
> > 3) XML applications are all data based applications, whether 
> > you call documents data as a structured formatted element, or 
> > data as a set or group of elements. IE there are no XML 
> > applications that do not contain or process data elements.
> I find it hard under that definition to imagine any IT applications that
> are not data based. I think you are fudging terms. Not all "data-based"
> applications are "database" applications.
> > 4) Rigorous, scientific proofs exist, and are easily found, 
> > for adherence to the Relational Model (RM). Saying that 
> > something supports SQL does not say it can implement or 
> > adhere to RM, because SQL support does not require RM 
> > compliance or support per se.
> Yes, Codd's 12 rules are reasonably objective as these things go. The
> trouble is, when you try to use them, they tell you that every real
> system is not relational, which isn't very helpful.
> You seem to be confusing the existence of rigorous tests that show
> whether a system is relational with the existence of rigorous proofs
> that show that relational systems deliver specific engineering benefits.
> The latter are sadly lacking - we have to rely on anecdotal evidence for
> such judgements. 
> > 5) I have seen nothing better than RM for improving software 
> > application reliability, flexibility, maintainability and 
> > lowering software system costs overall. If something better 
> > exists, as a methodology with scientific proofs, I would 
> > dearly like to see it.
> You're telling me that you trust your own unscientific anecdotal
> observations to show the merits of the relatational model, and you won't
> accept anecdotal evidence that other things might be better? Sounds a
> bit biased to me...
> Remember that Codd himself spent a lot of time and energy trying to
> improve the original relational model, in particular by enhancing its
> semantic richness.
> Your real mistake is in assuming that the world is one-dimensional, that
> there is only one measure of goodness. Different technologies are good
> at different things, there are a range of metrics that you can apply to
> them, and they give different answers.
> > 
> > So. My point is that I have not seen a rigorous, scientific 
> > proof for RM via XML or any XML tool set.
> You're not being clear. What assertion do you want to see proved?
> > 
> > This leads me to conclude that a very high probability, 
> > almost a certainty, exists that any XML application will 
> > endure the specific issues which RM was designed to resolve. 
> > Especially large scale data based applications featuring 
> > significant or exclusive XML usage.
> Sure. It's highly likely that if you measure a system by the things that
> the RM does well, then anything else will not do as well. It's also easy
> to find things that the RM does badly, which other technologies do far
> better.
> A couple of years ago I saw some people trying to do data integration of
> heterogeneous databases entirely using direct SQL mappings of one to the
> other. It was awful. Every time any of the databases changed, the whole
> thing broke. XML as an intermediate representation of the data model
> would have worked far better. The reasons for this are well known - SQL
> simply doesn't have enough semantic richness, enough power of
> abstraction, enough ability to handle complexity. Minor changes like
> allowing a customer to have more than one address require a complete
> redesign of the data structures.
> (I saw another system that did daily data interchange, between two
> different companies, in the form of a binary image of a SQL server
> database. Neither company was able to make any changes to its software
> configuration because of fears that the transfer would stop working.
> This is the kind of nonsense you get when you pursue the "it's
> relational so it must be good" line of reasoning.) 
> > 
> > As a Software Engineer, someone who majored in Computer 
> > Science, I have grave concerns about applications already 
> > deployed, or in development, that make significant usage of XML.
> >
> Then you should have even graver concerns about any system that does
> data interchange using proprietary ASCII files, which means almost every
> real IT system in live use.
> The challenge in large scale IT systems is to manage heterogeneity, to
> keep the components well isolated from each other so that they can
> evolve independently, generally to achieve loose coupling. XML is
> ideally suited as the technology to use at the interface between the
> components. The relational model works well for managing the local data
> within each component, so long as it is not too complex, but as an
> integration technology, it is hopelessly flawed. 
> Michael Kay
> -----------------------------------------------------------------
> 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://lists.xml.org/ob/adm.pl>


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.