RE: A standard approach to glueing together reusableXMLfragme
<quote>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. </quote> 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. http://www.cis.ohio-state.edu/~sgomori/570/coddsrules.html 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. :) rick > 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>
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