From: SP
To: Editor
Date: 5 Apr 2004
I've got THE THIRD MANIFESTO
on my desk at home, and it’s been pretty well read. I'm getting ready to start my third reading of it - very good
stuff, I have to thank you for writing it.
I stumbled on this stupid paper today on the web, and found
where the author has horribly misrepresented THE THIRD MANIFESTO. Note that reference [3] is Date's THIRD
MANIFESTO book in his "References" section.
I don't think it’s worth the bits to even attempt to reply to
this guy's article, but thought you might like to know your work is being
misrepresented in the "oh-so-well-regarded" Journal of Object
Technology.
Hugh Darwen Responds: The mistake in Dave Thomas's
paper (which I downloaded to see the whole thing in all its glory) is
bizarre. Item number [3] in the
REFERENCES section gives the title of a book by me and Chris Date, this book
being, as many people know, the follow-on from our paper entitled THE THIRD
MANIFESTO, which was first published in 1995 (in the ACM journal
"SIGMOD Record"). But the
text Shawn cites seems to assume that reference [3] is in fact a reference to
what Chris and I would probably call "the second manifesto", the one
entitled The Third Generation Database Systems Manifesto. I find no fault with the text Shawn cites
apart from that "[3]"!
I couldn't find any other reference to [3] in the paper, nor
did I see any text acknowledging the existence of THE THIRD MANIFESTO
apart from that third entry in REFERENCES.
The misrepresentation of me and Chris, then, is in "the
DBMS vendors replied with the Third Generation Database Manifesto [3]",
combined with:
[3] C. J. Date, Hugh Darwen, Foundation for Future Database
Systems: The Third Manifesto, Second Edition, Addison-Wesley, 2000 (ISBN:
0-201-70928-7). </quote>
I suppose that people who happen to know that I work for IBM
might think that the appellation "DBMS vendors" is very roughly
justified (for me, that is), though of course my books with Chris Date have
nothing to do with my work for IBM.
Thus, Dave Thomas's mistake does run the risk of seriously misleading
some casual readers. It's even more
serious, if any readers might conclude that Chris and I would advocate the use
of SQL and extending that language as the best way forward. I see that one can click on "Write a
letter to the editor" at www.jot.fm/issues/issue_2003_09, though I'm not
sure if I'll bother myself.
I think that the real authors of The Third Generation
Database Manifesto might have a grievance or two about this bungled
citation. For one thing, I'm not sure
that they would like to be classified as "DBMS vendors". I can't remember the entire list of authors,
but I doubt very much if the IBM and Oracle employees among them (for example)
were acting in any kind of representative capacity for their employers.
As for Dave Thomas's paper, all I can say is that this kind
of stuff makes me shudder. I found the
term "tuple land" rather revealing, completely missing the point of
what Relationland is all about! The
last two sentences of the paper are:
We need to apply our considerable efforts to developing
languages/tools as simple and useful for business users as 4GLs have been and
continue to be. We need a computationally complete end user programming
language, which will allows [sic] a mere mortal to create and deploy
applications across a federated collection of semi-structured information.
Apart from the fact that I don't know what it means for
information to be "semi-structured" (or even "structured",
for that matter, given the normal distinction we try to foster between
"data" and "information"), and apart from the fact that I
don't really know what a federated collection is, and apart from the fact that
I don't know what it means to deploy an application across a collection of
information, it seems to me that THE THIRD MANIFESTO was an attempt to
address the stated requirement. Or at
least, to propose a method of addressing it.
Still, I'm glad that the author chose to ignore it (apart from the
mistaken entry in REFERENCES), because otherwise I can see that Chris and I
might have had to respond to some genuine misrepresentation of a more serious
kind.
From: SP
To: Hugh Darwen
I'm guessing that Thomas must be trying to refer to a concept
similar to federated simulators in a discrete event simulation. The DOD came up with this concept at least 6
years ago (probably more) where the DOD wanted to tie unrelated warfare
simulators together into a larger battlefield simulation. Different branches of the military (and
different research projects within them) had their own simulators, which were
incompatible with each other, with each simulating some part of a larger
battlefield. The brainstorm idea was to
run them together to see what an actual battle would be like when different
branches were cooperating on the battlefield.
For the most part it worked, but the combined system is horribly slow
and extremely complex. The different
simulators never had the same data model, or calculated simulated time the
same, used the same network protocols for communication, etc.
Thomas, or someone he is trying to emulate, must have read
about the federated simulators concept, stolen the term, and made it into one
of the newest buzzwords. At least some
academic research is still heading out of the labs and into the world of
corporate insanity. Unfortunately in
this case its just one word out of two, which simulation researchers have come
to accept as a term (federated simulators).
*Sigh*
I fell on Thomas's paper while doing a Google search on an
unrelated topic. After reading it, I felt a little dumber, and wondered what
just happened to the last 15 minutes. I
wish I could get them back!
After reading Date's INTRODUCTION TO DATABASE
SYSTEMS (7th or 8th edition, I forget which edition I have at home)
twice, and your/Date's THE THIRD MANIFESTO (doing my third reading now),
as well as reading the dbdebunk.com website, I've learned to at least look for
the bulls--and dig a little deeper into the topic. Thankfully, I've also learned a little bit more about what Codd
meant, and I'm quite annoyed the SQL vendors have deviated so much from
it. Our commercially available tools
just flat out stink. I've started to notice this in the world of
object-oriented programming to... C++, Java, C#... *sigh*
I have to thank you, Date and Pascal for putting forward the
effort you do, it has at least changed this practitioner. But then of course I
have at least been considering working on a PhD in database management, so I
wasn't the average practitioner when I started reading your work.
C. J. Date Responds: My attention was recently drawn
by two correspondents--to whom I owe thanks (I suppose)--to the article The
Impedance Imperative--Tuples + Objects + Infosets = Too Much Stuff, by Dave
Thomas in Journal of Object Technology 2, No. 5, September-October 2003.
I have many problems with this article in general, but I want to respond to
just one issue here. The article
includes a section called Minimal Affordances for Objects and Content [sic]. Here is the whole of that section:
In order to accommodate the increasing demand for objects and
content, the DBMS vendors replied with the Third Generation Database Manifesto
[3]. In particular they added new
native types to the database to support objects (called user defined data
types) and large text types. Both of
these extended types were syntactic extensions on Blobs, which were added
largely to support images, and documents.
SQL was extended to allow query operations over Blobs using special
content selector objects. Recently text
types have been enhanced to support XML schemas or DTDs.
Now, Thomas's reference [3] is in fact not a reference to the
Third-Generation Database System Manifesto at all--which is a paper by
Mike Stonebraker et al.--but rather to the book by Hugh Darwen and
myself called FOUNDATION
FOR FUTURE DATABASE SYSTEMS: THE THIRD MANIFESTO (2nd edition,
Addison-Wesley, 2000). So I have to
assume that, despite what he actually says, Thomas is talking here about the
work by Darwen and myself. Given that
premise, here are a few comments on Thomas's text:
In order to accommodate the increasing demand for objects and
content, the DBMS vendors replied with the Third Generation Database Manifesto
[3].
First, Darwen and I can hardly be accused of being "the
DBMS vendors"! Second, our work
had and continues to have absolutely nothing to do with "accommodating the
increasing demand for objects and content". Third, what on Earth does the phrase "objects and
content" mean, anyway? I thought
it was a mantra that "everything's an object"--so what isn't an
object? What database doesn't contain
objects? And what database doesn't
contain content?
In particular they added new native types to the database to
support objects (called user defined data types) and large text types.
First, is "they" here supposed to refer to Darwen
and myself? We certainly did nothing of
the kind alleged. Perhaps more to the
point, I don't think the DBMS vendors did, either. Second, "to the database" makes no sense; types don't
belong to databases at all. (Which
database does type INTEGER belong to?)
Third, objects aren't types--not of any kind. Fourth, native types aren't user-defined data types and
user-defined data types aren't native types, so there seems to be some
confusion here. Fifth, that "and
large text types" adds nothing; presumably, a large-text type (that large
must qualify text and not type!) is just a special case of the
category "object type" (as, presumably, is every other type
also). Perhaps Thomas meant
"including large-text types in particular."
Both of these extended types were syntactic extensions on Blobs,
which were added largely to support images, and documents.
Confusion here (regrettably all too common) over syntax vs.
semantics! If the extensions were only
syntactic, they wouldn't have been much use.
In fact BLOBs have nothing to do with the issue; while it's probably
true that BLOBs are used to implement the new types, we mustn't confuse
model and implementation again, must we?
Note too that we now apparently have another kind of type (an extended
type) as well as native and user-defined types. What others are there?
SQL was extended to allow query operations over Blobs using
special content selector objects.
No, the new data types were (necessarily and by definition)
accompanied by new operators, and those new operators became invokable (if
that's a word) from SQL. But those new
operators are operators on values and variables of the new types, not on
values and variables of type BLOB. And
I can't make any sense of the phrase "using content selector
objects," if "content selector objects" are supposed to be
things that are used in "query operations over Blobs."
Recently text types have been enhanced to support XML schemas or
DTDs.
Possibly. But I think
it's much more likely that still more new types would have been defined (with
all that that entails). Certainly this
latter is what the SQL standard has done.
And I don't really know what it would mean for a type to "support"
XML schemas, anyway.
I have many, many additional criticisms of Thomas's paper,
but to spell them out in detail here would result in a document much longer
than Thomas's original. So I'll stop.
Posted
6/18/04
