2004 QUOTES

The weekly quotes contain errors that anybody with basic knowledge and understanding of data fundamentals in general, and the relational model in particular should be able to identify. The  purpose of the quotes is two-fold and educational (a) to demonstrate lack of foundation knowledge in the industry and alert practitioners to it (b) as a means to test oneself on grasp of data and relational fundamentals. The reader unable to recognize the errors is advised to pursue proper education, but exercise extreme care with respect to the quality of sources providing such (the site does provide some recommendations).

Top Ten Tomes The best-selling "database" books on Amazon.com 1 PHP and MySQL for Dynamic Web Sites 2 Beginning PHP and MySQL: From Novice to Professional 3 Microsoft Office Access 2003 Step by Step 4 Microsoft Office Access 2003 Inside Out 5 Teach Yourself SQL in 10 Minutes 6 High Perfomance MySQL 7 MCAD/MCSE/MCDBA Self-Paced Training Kit:Microsoft SQL Server 2000 Database Design 8 MCAD/MCSE/MCDBA Self-Paced Training Kit:Microsoft SQL Server 2000 System Administration 9 MySQL, 2nd Ed. 10 Professional SQL Server Reporting Services --Software Development Magazine 12/10/2004

It's one thing to say that either SQL or XQuery have their problems, because they do. It's quite another to say that SQL is bad because it doesn't live up to some arbitrary never-achieved (and perhaps unachievable) standard of relational purity that even Codd himself found superfluous. When Pascal does nothing but the latter, and in addition takes a dozen thoroughly unprofessional swipes at Chamberlin for having been involved in both SQL and XQuery, his professional jealousy is becomes thick enough to choke on. I wish he would, so we would be spared the incessant ranting of someone whose whole career has been marked by a lot of words and not a single deed to back them up. --Salamander, slashdot org 12/03/2004

Now that I've been developing databases for 10 years. I'm starting to realize that a completely normalized database is far too complex to work with. Sure, it all works and looks great on paper, but it basically becomes a castle made of cards. If you change one table the entire database application can break. I've noticed that some front end database applications change so frequently that normalization can't handle it. I also think that enforcing referential integrity is over rated. I would much rather maintain database integrity with with stored procedures and well written application code. --00kevin, sqlteam.com/forums 11/26/2004

One of the remarkable extensions of the Oracle database is the ability to reference Oracle objects directly by using pointers as opposed to relational table joins. --Donald Burleson, Using Oracle Nested Tables, Praetoriate Oracle Support 11/19/2004

I love how people bash SQL for not following the model, when in my experience SQL follows reality (isn't that the real key here?) better than the model. --TheGavster, slashdot org 11/12/2004

It's boolean logic that's broken. More exactly, inapplicable. If the presence of any unknown makes it impossible to represent everything that is known, you've got some serious problems. The real world is rather more complicated than a trite boolean logic world. --Tony-A, slashdot org 11/05/2004

I didn't say no one should point it out. Pointing it out is fine and good. Beating a dead horse is just annoying and useless. I'm an academic myself (not of sorts, a real academic), not a coder. I'll point out problems in discussions in papers I write, but I don't rant on and on endlessly about things like this. Point out the problem. Then suggest feasible ways to move forward if you have one. Ranting on and on in a forum like this (which is going to consist of almost entirely end-users) that someone is incorrectly using the nuances of the word 'relational' (without properly explaining it in the fist place in his rants!) is not just useless, but annoying. Just bitching over and over doesn't progress science. He likes to hear himself talk. That's about it. Sorry, but THE THIRD MANIFESTO is almost a decade old. Nothing material has come of it. Academicians all over the world are working on the problem of finding a working relational system, and companies like Oracle and MS are throwing lots of money at it. Finding a working truly relational replacement for SQL is non trivial. A lot of very bright minds have taken on the task. One day I'm sure someone will come up with one. In the meantime, folks who are in the field already understand that SQL isn't really relational. Beating the dead horse isn't making anyone’s work progress any faster. --LurkerXXX, slashdot org 10/29/2004

Don't use joins ... Oracle and SQL Server have fundamentally different approaches to the concept ... You end up with unexpected result sets ... You should understand the basic types of join clauses ... Equi-joins are formed by retrieving all the data from two separate sources and combining it into one, large table. Inner joins are joined on the inner columns of two tables. Outer joins are joined on the outer columns of two tables. Left joins are joined on the left columns of two tables. Right joins are joined on the right columns of two tables. --Sanders Kaufman, Code for DBMS Independence, builder.com 10/22/2004

Anonymous Coward: Maybe instead of dismissing Pascal's comments as a "psuedo-academic argument", you should read some of his books where he fleshes things out in greater detail. Localman: Maybe I should. But I've been too busy keeping up with the real-world business demands of my employer for the past several years. And during that time (and before) I can't recall ever seeing a good ROI for clever data modeling ... And mathematics is an incomplete and inaccurate description of the real world; and the real world is where I work. I'm not saying that justifies making sloppy languages or not trying to get things as clean as you can. My point is that it's incompleteness and inaccuracy don't appear to be a hinderance to it's practicality. If Date & crew realize that, great. I wish them much luck in coming up with a new system that I may use and love some day down the road. If it's superiority outweigh the transition costs, that is. --slashdot org 10/15/2004

Q: We are a not-for-profit organization that is looking for a suitable Linux-based database to suit our needs. MySQL is looking good but I haven't seen the term "relational" used with MySQL. Is it because it is really the foundation for any database that could in fact be relational or because it is not natively supported? Also would you recommend any existing open source MySQL databases that would suit the needs of CRM, etc? A: Any database that allows you to establish a relation between different pieces of data is a relational database. MySQL is a relational database, in that it allows tables to be joined together and also supports the concept of foreign keys. As for CRM, it depends on whether you are planning to develop your own or acquire a CRM solution. MySQL is well suited to serve as a back end for a CRM solution, one MySQL partner providing CRM solutions based on MySQL is SugarCRM. --Mike Hillyer,Ask the Database Expert, Target.SearchDatabase.com 10/08/2004

The academia is forgetting the whole point of XML. "XML is not meant to be read by humans, it's a data interchange format and thus meant to be read by machines" - Good heavens! Someone saying something like that has really got a BS in BS! Or perhaps even worse: a PhD in BS. XML is all about programmers being able to understand the data! Yes, because we are not anywhere near that nirvana of fully semantic systems that can (semi)automatically understand each other. NO! Programmers have to do the work to make the systems fit together and XML gives them the advantage that they do not have to reverse engineer another proprietary data format or dig into a horsepile of documentation. XML makes it easy to understand how to process the information at hand - without any extra work! Also it's great format for storing small amounts of constantly changing data (like user preferences) cause it's extensible and with only a tiny bit of effort backward compatible as well. Anyone trying to use XML for processing large amount of data (like data warehousing) is either nuts or doesn't give a damn about the speed or costs. However anybody using XML for long term data storage is a genius since other "more efficent" formats will be obsolete ten years from now and the software that can read it can be extreamly difficult to obtain (anybody who has tried to decode data from some long gone accounting package from the '80-s knows what I am talking about). So yes XML is self describing only to humans and that's the whole point of it. Formalizing data semantics is not the goal of XML, has never been and will never be, thats what we have RDF, RDFS, OWL and other nice initiatives from Semantic Web movement for. --anttix, slashdot org 10/01/2004

By technical I mean the point of this class is not to teach theory, not to teach opinion, not to teach buzz words and not to teach what any corporation, including Oracle, wants taught. Technical means code! And while we teach the course using Oracle we cover aspects of DB2, Informix, SQL Server, and Sybase too. We can't get free copies of every RDBMS on the market for the students and, quite frankly, the students have expressed close to zero interest in DB2, Informix, and Sybase. At least here in the Northwest the only players are Oracle and Microsoft. Perhaps not in some 19th century view of the purpose of academia but most certainly incorrect in terms of how it views its mission at present.And if not at the university where is the student to gain the expertise and where is the organization to gain skilled employees? We are in a product-oriented industry. There are few analogs in medicine or engineering but they most certainly do exist. One does not learn how to install a generic pacemaker ... one learns to install a particular brand of pacemaker. One does not learn about cancer treatment as a generic subject but rather as pharmacology with the application of specific branded medications in specific cases. There is no difference between telling a physician to give Xeloda for breast cancer and telling a software engineer to apply Real Application Clusters for high availability: Both are product specific solutions to technical problems. --Daniel Morgan, Oracle Application Development Certificate, University of Washington 09/24/2004

If you removed NULLs from relational database design, people would reinvent them (poorly) -- probably by using IDs of -1 or 0, or IDs to a special magic "null" row, which I suspect is what he's talking about by "it can be handled relationally." To suggest that missing or inapplicable values are not part of "the real world" is so wrong it's... well... wrong. Anyone who's actually done database work (or programming work, for that matter) knows this. --Chops, slashdot org 09/17/2004

Object-oriented supporters and relational database proponents are still debating various issues to this day. Both sides agree that the relational database will not work for certain types of applications, but disagree as to the appropriate solution to the problem. The issues are quite complex and well beyond the scope of this work, but suffice it to say that these debates are likely to go on until one side gives up or technology renders them irrelevant. --Michael Hernandez, DATABASE DESIGN FOR MERE MORTALS 09/10/2004

I once did a metadata repository for a manufacturing company. Part of the model was the physical data structure found in that organization. They wanted to keep track of databases, tables, column names, etc. of the various systems (applications) used in the company. They also wanted to relate these data structures to the logical structure (entities and attributes), but that's another story. --Doug Swetland, http://www.dbforums.com 08/27/2004

Interesting, and proof that Joe Celko is an idiot more interested in academic arguments than real world systems. Any app[lication] that uses business data (ISBN, SSN, VIN, UPC, etc) as keys is pretty much guaranteed to break. --Anonymous Coward, http://www.slashdot.org 08/2020/04

The author fails to mention is that the S in SQL is for STRUCTURED, as in structured (aka. relational) data. Hierachical databases are by definition unstructured (LDAP, SleepyCat, etc). So no shit, SQL doesn't mesh well with XML dbs, it was never meant to. --molarmass192, http://www.slashdot.org 08/13/2004

Interestingly, the inability to integrate relational and hierarchical processing is similar to the division between the theories that define the principles governing the behavior of objects in the universe. There are two incompatible theories, the theory of general relativity governing large objects and the quantum theory governing very small objects like subatomic particles. The problem is that there should only need to be one unified theory governing all objects. --Michael David, The Marriage of XML to ANSI SQL, www.datawarehouse.com 08/05/2004

Ok, so you break down the XML by its structure. Now how do you do a valid query on it? Since you've completely dereferenced its structure and stuck it in a relational model, you've cut yourself off from the prospect of doing XPATH type queries. Instead, you'll need to make multiple (perhaps hundreds?) of passes at the table to reconstruct its data structure. XMLDBs don't have this problem. They deal with the XML in its natural form and are thus able to index, order, and query in that fashion. As I said before, you can do many of the same things with an SQL database as you can with an XML database. That's not the point. The point is working with the data in a form that is natural to it and will provide the best results. --AKAImBatman, http://www.slashdot.org 07/30/2004

XML is object-oriented While the relational data model is very successful for processing large amounts of table-like data, manipulation of other kinds of data - such as hypertext (i.e. text plus hyperlinks), multimedia, graphics, mathematical or chemical formulas, hierarchical information - are not so straightforward. In contrast, XML is object-oriented in the sense of being suitable for describing objects of the real world or any abstract problem domain by modeling their properties as they are, instead of enforcing a normalized decomposition into various tables linked by relations. This makes XML documents more intuitively understandable and thereby reduces both the time required to design and implement computing systems based on XML. --XMLSpy documentation 07/23/2004

Fabian Pascal is smart and well-informed, but a zealot. Like all zealots he is willing to sacrifice anything and everything for his vision of technical purity. One of his specific complaints is about SQL NULL values being "unrelational"... The simple fact is that the world is full of optional, single-valued data. NULL-allowed columns express that data efficiently, without confusion, and without breakage. Community college database designers have no trouble using the convention productively. It may be a little inelegant, but it is pragmatic and balanced engineering. The only whining you hear is from zealots like Pascal who heap fire and fury on others, but never seem to deliver the mythic PerfectoRDBMS. --negative video, http://www.slashdot.org 07/16/2004

JPT: Have your original ideas about O/R mapping changed much since you embarked on this project? GK: I went into this knowing very little about ORM, and even very little about databases. One of my first tasks was to go out and buy a book to learn SQL properly. All my understanding of the problem comes from what our users have taught us over the last two years. --The Interview: Gavin King, Hibernate, http://www.javaperformancetuning.com 07/09/2004

And yes, there are better (i.e. more succinct, and hence easier to process) ways to represent the semantics of programs than XML, but we believe that will turn out in practice to be irrelevant. XML can do the job, and is becoming universal; it is therefore difficult to imagine that anything else will be so compelling as to displace it. --Dr. Gregory V. Wilson, Programming For the 21st Century, http://www.third-bit.com 07/02/2004

Storing hierarchical data is orders of magnitude easier in XML than it is in an RDBMS. Storing DAGs is orders of magnitude easier with structs and pointers than it is with an RDBMS. RDBMSes are good at manipulating unordered sets with ultimately simple relationships between them. They handle 1:1 and 1:N relationships and... that's it. If you think that that's adequate to cleanly deal with all but the most trivial data access tasks, well, lucky you, I guess. --PeterB, http://tinyurl.com/2m2f8 06/25/2004

The widespread use of XML data and the Web has brought about new demands on traditional database engines. Traditional database engines, backed by more than 20 years of research and engineering, are well-known for their efficiency in managing large volumes of relational data (i.e., data that occurs in rigid table-like structures). Their ability, however, to efficiently manage XML data, which may not conform to a table structure, is still very much at the infancy. --Wang-Chiew Tan, Course Description, U. of CA, Santa Cruz 06/18/2004

With RDBs relationships are implemented using foreign keys to other entities and are "traversed" via joins. You can effectively traverse them in either direction, regardless of which table they're implemented in, making them bi-directional. It is possible, however, to implement uni-directional associations using object technology, something that you can't do using relational technology. Hence it's a minor addition to the technical impedance mismatch. --Scott Ambler, Scott Ambler and His Strawman, google.com/group/objectiveviewdiscussion 06/11/2004

Despite the popularity of the relational model, it was often used as an implementation technology largely due to the need to have normalized tables. [?????] Information architects and business modellers used the more expressive and simpler Entity Relationship (ER) model (born again in UML). In order to implement a relational schema and associated operations, analysts and designers who work at the application level are forced to mechanically translate to an underlying relational model. It is surprising, given the utility of the Entity Relationship (ER) model [hahahaha], that there were few ER databases or at least ER languages other than ZIM. --http://www.jot.fm 05/28/2004

The distinction in modeling flexibility deals with the expressiveness of the data model that can be created from multiple data sources (see Table 2). This is largely dependent on the underlying logical data model and the ability of the transformation framework to mold data structures into the new logical model. In this regard, the object and XML approach have an advantage over the relational approach because of their ability to support hierarchical data relationships. Their logical data model can directly represent hierarchical data whereas the relational approach must decompose the data structure into tables. In addition, the object and XML approach can represent hierarchical data sources like XML, whereas the relational approach requires the application developer to reconstruct the hierarchical data in application code. --Peter Chang, Which EII Solution Is Right For You?, Java Developer's Journal 05/21/2004

The schema is what the data *means.* First your definition does not match others. Per dictionary, a schema is an underlying organization pattern or scheme. Yes. It is this underlying organizational pattern or schema that determines what the data means. In TDM/XDb1, it is nearly the reverse. No schema determines what data means. Instead, the current data can be used to derive schemas of any level of generalization. --Exchange, comp.databases.theory 05/14/2004

Q: It's not clear to me you know what "normalized" means. Can you be specific about what normalization rules you are referring to? In what way is my schema not normalized? A: Normalization: The process of replacing duplicates things with a reference to the original thing. For example, given "john isa person" and "john obeys army", one observes that the "john" in the second sentence is a duplicate of "john" in the first sentence. Using the means provided by your system, the second sentence should be stored as "->john obeys army". Another example, given "bob" one observes that the second "b" is a duplicate of the first "b" and therefore should be normalized as "bo->b". I don't want you to normalized [sic] this far, even though Ex076 is. The exact method of normalization and to what extent is practical is dependent on the data model and its implementation. Sorry, I just realized that I don't want you to explicitly represent the relators [sic] "obey", "isa" or "is". They can be implied. --Neo, comp.databases.theory 05/07/2004

Every doctor likes to keep records her or his own way. However, a software solution that provides doctors with customized recording options likely requires a degree of customization no small business or workgroup can afford ... Right off the bat they could see the underlying problem with current canned products: They all relied on relational database management systems (RDMS), and plain RDBMSs weren't built for this kind of business situation. Relational data models are inherently inflexible. To store information using the relational paradigm, you need to build the entity/relationship model first. Such a model is fixed, and if you need to add new information, you must design and code a new model. --Lee The, Use XML Where RDBMSs Fear to Thread 04/30/2004

MySQL allows you to create a column of type CHAR(0). This is mainly useful when you have to be compliant with some old applications that depend on the existence of a column but that do not actually use the value. This is also quite nice when you need a column that only can take 2 values: A CHAR(0), that is not defined as NOT NULL, will occupy only one bit and can take only 2 values: NULL or "". --mySQL manual 0423/2004

But no decently designed object system that I've worked on (let alone a poorly designed system) has found an elegant way to interact with databases. Sure, DBI makes things easy for Perlers in that it provides a pretty standard, uniform interface for accessing databases of all kinds. But if you're designing even a moderately sophisticated application, you still run up against the complete incompatibility of object-oriented design and relational storage. They're just completely orthogonal to one another. --All RDBMSs Suck, http://use.perl.org/~Theory/journal 04/16/2004

With their exclusive focus on data (and ignoring behaviour) RDBMS's can't be trusted anyhow. For that you'd need an ODBMS. --Stephan Eggermon, http://www.dbforums.com 04/09/2004

I would suggest the OP investigate Multi-Value (or Network, or hierarchical, etc - basically something that's NOT an *R*DBMS). The databases I work with are NOT 3NF, but will quite happily maintain integrity provided they're defined properly - delete an object and all related data disappears with it, and you can't assign values to attributes without declaring the object they belong too. People today assume DBMS == RDBMS, and that's a pretty stupid assumption to make ... --Anthony Youngman, http://www.dbforums.com 04/02/2004

I'm a 3rd year student of the Palermo University on Systems Analisys. I'm conducting a research on how the clasical structure of the databases is not allways the better option in terms of performance. The research is going great, but I need some real cases of violation of the Normal Forms (and BCNF) in order to improve some [any] aspect of the database, to support my theory. So I ask you please to help me on this. I would need some real databases STRUCTURES (no data) with this kind of violations and the reasons to implementing this. I would proudly name any helper in my research and any help you can give me, and of course, if you like me to, I would send its complete version once finished. --http://www.dbforums.com 03/26/2004

SQLite is "typeless". This means that you can store any kind of data you want in any column of any table, regardless of the declared datatype of that column. (See the one exception to this rule in section 2.0 below.) This behavior is a feature, not a bug. A database is suppose to store and retrieve data and it should not matter to the database what format that data is in. The strong typing system found in most other SQL engines and codified in the SQL language spec is a misfeature - it is an example of the implementation showing through into the interface. SQLite seeks to overcome this misfeature by allowing you to store any kind of data into any kind of column and by allowing flexibility in the specification of datatypes. Even though SQLite allows the datatype to be omitted, it is still a good idea to include it in your CREATE TABLE statements, since the data type often serves as a good hint to other programmers about what you intend to put in the column. --http://www.sqlite.org 03/12/2004

The reason that hierarchical filesystems have survived for so long is due to one thing: navigability. It's relatively easy for any user to browse what's on the system and get a good idea of how it is organized. You can't navigate a relational system, which will prove to be the downfall of any all-relational system which comes into being. You can, of course, do a SELECT * FROM volume if you really want to, but that does exactly that: it gives you all the data, with no particular organization. Examining the entire "sea of data" suddenly becomes cumbersome in the extreme. So while User A might be able to set up an all-relational filesystem completely according to his own tastes, User B will be totally lost on that same system. This is, to say the least, a nightmare for anyone working in a shared environment. --Online exchange, http://slashdot.org 03/05/2004

A few years ago there was a sudden rush to embrace the idea of the relational database. The whole notion is fairly theoretical, yet it suddenly became important for every database on the market not just to be a database system (DBS) [sic], but a RDBS [sic]. In some cases this claim was clearly a nonsense, and today the hangover is SQL servers that really go beyond what any pure relational database should do. But who cares? The whole "relational" idea was silly in the first place - a theoretical idea made to meet the real world. --Mike James, Editorial, Visual Systems Journal 02/27/2004

Like all relational databases, Oracle stores data in logical structures called tables. Conceptually, a table is a collection of rows and columns, similar to a spreadsheet, where each cell contains a data value. The database is called "relational" because many of the tables it contains are related to one another. Such relationships occur when two tables have one or more columns in common, allowing corresponding rows from each table to be joined together (linked) based on common column values. This relational concept is so simple and flexible that a set of related tables can be designed to store the data required by almost any conceivable information system. --IBM, Team Report, http://ftp.info.usaid.gov/ 02/20/2004

Never mind that set theory is just that - THEORY! Never mind that other forms of database are provably better in many circumstances. The MV engine allows you to program as if you had a relational database, or a tree database, or a hierarchical database or whatever. And I would strongly advise that a programmer should know those theories. But SQL carries a massive real-world performance hit (never mind the fact that theory and reality rarely coincide - why force a non-relational real world scenario into a relational straight-jacket?). The really big problem that MV suffers is that it is simple for users to understand. As a result there are far too many crap systems out there written by users for users. If MS Access is a nightmare for professionals today, so Pick ACCESS was a nightmare maybe 10-15 years ago. But with a pro who can design a database, normalise it, denormalise back into MV, and implement properly, you'll have a good system. And you'll end up with a better system, quicker than with SQL. --Anthony Youngman, http://www.dbforums.com 02/13/2004

The problem isn't with relational databases. It's trying to shove square pegs into a box with round holes. Relational databases are great if you're dealing with a small number of composable datatypes (e.g. columns and tables). But they're poor at dealing with highly structred and intricate datatypes (objects). The object/relational barrier is a well-known impedence mismatch. It's reminiscent of the difference in philosophies between Perl and Java -- do you start with a small number of powerful and interoperable types (scalars, lists, hashes and references), or do you start with a a big object hierarchy? --Ziggy, http://use.perl.org/~Theory/journal 02/06/2004

I think relational, program MV. So if we talk the relational language of entity, attribute, relation, ALL my tables are entities. Every "row" is an instance. All my attributes and relations are stored in the entity table. That's how I achieve integrity. But because relational is a very good theory at the first approximation (Newton's gravity :) it works very well. I can flex my way round problems, but take advantage of SQL's strength. --Anthony Youngman, http://www.dbforums.com 01/30/2004

RDBMS is a database where we can break a bigger table into smaller ones (for ease of maintainance, low requirement of space, performance efficiency etc.) and create relations between the tables that are maintained by the RDBMS. For eg. lets say there's an emp table with emp details, salary, their performance et al. There will be data redundancy bcoz of lot of repetitions. now in a Relational database, we break it into let's say 2 tables-one maintaining details, the other one sal and performance. There is one field that connects the 2-let's say emp-id. Now if there's a change in address, only one table is updated which is smaller than that in a non relational db. Now if a reprt is reqd wherein the manager wants to check on the performance, then we generate it from the sal table, and his name is pulled out from the other table. --Ambalika, Online Exchange,http://www.dbforums.com 01/23/2004

And it's in exactly this scenario that Pick will score. It will ABSOLUTELY FLATTEN almost any other database for speed. SQL-based databases have query optimisers. Why? Because an unoptimised query is so inefficient that improvements of one or two HUNDRED percent are easy to achieve. Pick doesn't have optimisers, because even to achieve two or three percent would take performance beyond excellent, through perfect, into the mathematically impossible. --Anthony Youngman, http://www.dbforums.com 01/16/2003

>>That UNION statement causes a SORT to remove duplicates - and appart from the fact the the results will not >>be same as compared to the join because of the duplicate removals, sorts are pretty expensive... You could >>use SELECT ALL and UNION ALL, but dupes are an abomination. Relational theory is based on set theory, and >>dupes break everything. Those are both bogus statements if ever i heard one (and by the way, I have heard many). Duplicate records in a cursor are a fact of life - accept it. Consider a table with a PK, and a select statement that does not include the PK in the select list -- perfectly valid, and quite common - and I submit that they are not, as you characterized them, an abomination. Duplicate rows in a table are bothersome, they do offer some problems when programming tables with them, but they do not violate ANY relational rules. --Roy Fine, microsoft.public.vb.general.discussion 01/09/03

The academia is forgetting the whole point of XML. "XML is not meant to be read by humans, it's a data interchange format and thus meant to be read by machines" - Good heavens! Someone saying something like that has really got a BS in BS! Or perhaps even worse: a PhD in BS. XML is all about programmers being able to understand the data! Yes, because we are not anywhere near that nirvana of fully semantic systems that can (semi)automatically understand each other. NO! Programmers have to do the work to make the systems fit together and XML gives them the advantage that they do not have to reverse engineer another proprietary data format or dig into a horsepile of documentation. XML makes it easy to understand how to process the information at hand - without any extra work! Also it's great format for storing small amounts of constantly changing data (like user preferences) cause it's extensible and with only a tiny bit of effort backward compatible as well. Anyone trying to use XML for processing large amount of data (like data warehousing) is either nuts or doesn't give a damn about the speed or costs. However anybody using XML for long term data storage is a genius since other "more efficent" formats will be obsolete ten years from now and the software that can read it can be extreamly difficult to obtain (anybody who has tried to decode data from some long gone accounting package from the '80-s knows what I am talking about). So yes XML is self describing only to humans and that's the whole point of it. Formalizing data semantics is not the goal of XML, has never been and will never be, thats what we have RDF, RDFS, OWL and other nice initiatives from Semantic Web movement for. --anttix, slashdot org 10/01/2004