OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] A standard approach to glueing together reusableXMLfragme

[ Lists Home | Date Index | Thread Index ]

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS