Letters

In his February 2001 "Editorial," Jonathan Erickson failed to mention why GNOME decided to take a separate route from KDE. One of the most important reasons was based on the licensing scheme of Qt (at that time) — it wasn't GPL.

Himanshu Gohel

gohel@csee.usf.edu

Parsing XML

Dear DDJ,

As the author of yet another XML parser (http://freshmeat.net/projects/xmltp/), I'd like to add a few comments to David Cox's "Parsing XML" article (DDJ, January 2001). David mentioned the event-driven and tree approaches to build an XML parser. I prefer a slightly different approach, which has [a] more object-oriented touch. Let me sketch the approach in a few sentences:

For each element (XML tag) the parser is supposed to understand, a class is registered with the parser. Such a class conforms to a minimalistic interface:

public interface Element {

void addChild(Element child) throws ...;

void addValue(String value) throws ...;

void addAttrib(String attrib, String value) throws ...;

void setParentElement(Element parent);

void close() throws ...;

...

}

Whenever the parser finds the start tag of a new element, it looks through its registered list of classes to find one which handles elements of that name. If the parser finds one, it instantiates an object of that class. The parser calls the appropriate methods of that just created object whenever it decodes corresponding input. The Element classes implement the semantic of an element, while the parser is only concerned with syntax issues.

The parser chains the Element objects to form a tree (by calling the addChild() and setParentElement() methods), so we have a mixed event and tree approach. Events are sent to a particular node in a tree. The Element classes can manipulate the tree chaining; they can "bail out" of the tree when the close() method is called by the parser to indicate that the corresponding end tag has been found. The result is that an Element implementation not only handles the semantic issues for an XML element, but also the data structure used to store the parsing results. Element classes completely encapsulate XML element data and behavior, as well as navigation information. This makes them powerful objects.

Thomas Weidenfeller

XMLtp@gmx.net

CPRM Frenzy

Dear DDJ,

The business with the Content Protection for Recordable Media (CPRM), as Jonathan Erickson discussed in his March 2001 "Editorial," is an example of what I have learned to call "the frenzy." Over and over again, someone, whose world is falling apart for reasons beyond his control, exaggerates his normal coping strategies until they become grotesque. One example would be the last independent Sultan of Morocco, who in 1894 more or less literally rode himself to death in a desperate attempt to maintain his authority in the face of French invasion (see Clifford Geertz's "Centers, Kings, and Charisma" in Local Knowledge: Further Essays in Interpretive Anthropology, Harper Torchbooks, 1983). When Microsoft's Jim Allchin began writing memoranda which could have come from a third-rate gangster movie, that was an example of the frenzy in operation. When people go into frenzy, they tend to do things which go wrong in such a way as to send them to jail. CPRM has obvious antitrust implications, quite apart from the fact that it obviously cannot work without operating system support. Given the stated attitude of Microsoft, which is hardly willing to get into more legal trouble without some benefit for itself, I cannot see how CPRM can have any real effect.

In fact, I may be missing something, but my impression is that major disk drive makers seem conspicuously unrepresented among the current CPRM backers. Seagate seems to have had the basic good sense not to attend the December 13, 2000 meeting of T13, which will inevitably be cited in trial briefs. Maxtor's representative voted for the proposal, but, judging by the protest e-mails which he has reposted and his insinuations that someone may have sought to conceal these, I think it is safe to say he has recanted. Quantum's man has put up a proposal to restrict CPMR to removable disks. Obviously, there is considerable peer pressure to make decisions unanimous, and a lot of these people are technological whizzes, but political innocents, who simply couldn't immediately grasp the necessity of talking to their lawyers before signing anything.

The movie industry is fundamentally threatened by the rise of the small movie producer using inexpensive equipment. DDJ's experience with the unionized cameramen was a special case of this (see "Editorial," DDJ, August 1999). What it comes down to is that large numbers of people are going to be producing movies, far more than can ever find a commercial market, and that most of these people will choose to give their work away on the Internet rather than be condemned to silence. Much the same applies for the music industry. Similarly, Intel can only look at things like Beowulf with terror. No amount of copyright or copy protection will do anything about the fundamental underlying problems. The spread of powerful personal computers is as fundamentally implacable as the French machine guns in 1894 were to the Moroccan swordsmen.

At the top of big companies, there are people with very few places to go when their worlds fall apart. "The only place for a deposed king is the grave," as one historian put it. The result is that these people tend to do supremely desperate things that are not in the interests of the shareholders, but merely serve to delay the fall of top management for a few months, then for a few weeks, and at last, for only a few days.

Andrew D. Todd

U46A8@wvnvm.wvnet.edu

DDJ responds: Thanks for your insightful letter, Andrew. Apparently IBM agrees with you, since it recently withdrew its support for CPRM as well.

Deadlock Detecting

Dear DDJ,

Time and again I am amazed when reading DDJ and find true the old maxim, the more things change the more they are the same. I hear all the time about the wonderful new technologies that should resolve all the old problems and make computing easier, safer, and so on. Yet, so many of the articles look like they might have been written 30 years ago.

For instance, regarding John Mount's article "Automatic Detection of Potential Deadlock" (DDJ, December 2000), the deadlock problem was well known and widely discussed in the '70s when the DBMS of the day was IDMS. The problem was never satisfactorily resolved with the advent of the RDBMS (the relational model) like DB2, Oracle, Sybase, and lately SQL Server. This fact is well known, so I was quite excited to read about a potential automatic solution for the problem.

Without taking away from John's great ideas and efficient implementation, his approach still does not resolve the basic problem. The example he gives is not wide enough for real-world, big-corporation situations. Let's look at an inventory database. Transaction A wants to look at specific warehouses and deal with items that are stored in them. Transaction B wants to look at specific items and deal with warehouses they are stored in. These two transactions are diametrically opposing each other by definition, and trying to force them to use the same hierarchical path will be (out of real life experience, not theory) inefficient and counterproductive, especially when we are talking about millions of different items and thousands of warehouses (think GE or GM for example) processed in a mixed online and batch environment. There was (and it is still a very efficient workhorse) a database that enforced this hierarchical view. It is the IMS that runs on the IBM mainframe. Rest assured that the deadlock problems on that database are extremely minimal! The limitations suggested in the article are akin to going back to that technology. There is nothing wrong in the technique John described, and the drive to bring most transactions to uniformity and prevent deadlocks by design is good. Moreover, such analysis is a necessary basis for a wider, more general solution. The real solution would probably lie, after identifying the potential deadlocks, in correctly scheduling them rather than limiting the access paths. The knowledge base acquired by lock analysis, as John described, could easily be stored in a database and used by the transaction monitor to postpone a transaction when a known potential deadlock could occur.

Ze'ev Atlas

zatlas@tact.com

Perl versus the World

Dear DDJ,

I was aghast at what I read in Michael Swaine's column "Alternatives To Java" (DDJ, February 2001). As a long-time reader of Michael's and subscriber to DDJ, I'm always interested in his perspective and have a chuckle. I stopped laughing on page 136 [where] Michael states: "What they can't claim, as Perl can't, are the benefits of a real, full programming language."

I was taken aback at Michael's ignorance of Perl and the power it has. Perl is no less of a "full programming language" than is LISP or C. It is inherently more secure than C (allowing for programmer error) and remarkably faster than Java.

If his comparison is to object-oriented languages, then no, Perl does not have reflection and some other bastions of OO-land. However, it does support, through the use of freely available modules, multiple inheritance and other standard OO methodologies. Does a lack of OO mean that C isn't a "full programming language?"

Perl stands at the heart of the Human Genome Project and was at the core of the U.S. Census. Perl is used by nearly every branch of the government for projects other than system administration and "CGI/Web work." Perl has applications in the geography, science, biology, mathematics, AI, business/finance, and home automation fields, to name a few. I'd heartily recommend Michael Swaine take a 30 second perusal of http://www.perl.com/ to become current with the language before his next reference to it.

I'm not picky about what language one uses — use whatever suits the task best. However, if comparisons are going to be drawn, please base the comparison in reality.

Dave Paris

DDJ