Playing by the rules

C. M. Sperberg-McQueen
cmsmcq@w3.org

Abstract

There are several types of rules: those that define an activity, and those that limit it. If you ignore the rules of chess, you aren’t playing chess. Similarly, there are some rules of XML that are absolute; if you don't follow them, you aren’t working with XML. Other rules, such as those involving expected patterns of thought, are regularly broken with good effect. It is often difficult to tell these two types of rules apart. If we are to survive, we must follow the rules of the game; if we are to thrive, we must break the rules.

Keywords: Technology Adoption; Markup Languages

C. M. Sperberg-McQueen

C. M. Sperberg-McQueen is the Architecture Domain Lead for the World Wide Web Consortium, an international membershp organization responsible for developing Web standards. He co-edited the XML 1.0 specification and the Guidelines of the Text Encoding Initiative, and serves as a co-chair of Extreme Markup Languages.

Playing by the rules

C. M. Sperberg-McQueen [World Wide Web Consortium]

Extreme Markup Languages 2003® (Montréal, Québec)

Copyright © 2003 C. M. Sperberg-McQueen. Reproduced with permission.

The title given in the program for this talk is “Playing by the Rules.” The topic was in some sense given to me in part by a passage in Donald Knuth’s book The Art of Computer Programming. A little while back I felt that I needed some intellectually challenging activity that wasn’t deadline-bounded, so I decided I would spend some time learning MIX Assembly Language. [audience amusement] This, as some of you will recall, is the assembly language for the fictional machine defined by Knuth to serve as a medium for communicating algorithms and discussing their costs in memory space and computation time.

I didn’t actually become a proficient MIXAL programmer — there are emulators around, so you can actually assemble a MIXAL program and have it run — but before I ran out of steam I did hit Exercise 22, which I will share with you now:

Location 2000 contains an integer number X. Write two programs which compute X13, and halt with the result in register A. One program should use a minimum number of MIX memory locations, the other should require the minimum execution time possible. Assume that X13 fits within a single word.

I’ll let you chew on that while I explain why this is relevant to my topic. I’m going to have to digress a little bit, and circle back …

Error checking and document grammars

When we talk about the reason why people might want to use XML or SGML, we talk, as Tommie Usdin did in her opening, about descriptive markup, about independence from specific applications, about future-proofing our data, about avoiding vendor lock-in. It is altogether fitting and proper that we do so, because those are strong advantages, potentially, of SGML and XML.

But ISO 8879 also contributed another innovation that I think is not always given its due, namely, the notion of explicit formal validation of data. The notion of formal validity is not itself new: logicians have distinguished for a long time between arguments which are sound, in the sense that we believe the conclusion, and arguments which are valid, in the sense that we agree that, if you were to grant the premises, the conclusions would necessarily follow. But applying the notion of validity and validation to documents and document processing is something that I have not seen in any system before SGML.

As far as I can understand, one of the primary impulses of this came not from the theoretical advantages of notions of formal validity, but from Joe Gangemi, who ran a typesetting service and knew that, if you could define the rules in a way that allowed them to be checked early, you could avoid keyboarding errors. If you avoid keyboarding errors, you avoid rework costs. If you avoid rework costs, you can underbid your competitors.

It is well known, in this as in other contexts, that early detection of errors will save you money because things cost less to fix early in the cycle than late, if only because, if only because if you don’t detect an error early, you may have to redo some arbitrary amount of work once you find the error. In practice, we all know that sanity checking of our input can take enormous amounts of time and effort. Who has not written a program that had a loop about this big [hands close together] that did the work, and sanity-checking clauses that gradually grew every time the program rolled over and you realized there was another condition you needed to check for? Who has not used a program where the sanity-checking had not yet grown enough? [audience laughter]

A few years ago there was an article in the Communications of the ACM, in which the authors had used a random-number generator to generate random streams of bytes to send to the standard Unix tools. It is humbling to reflect on how few of the standard Unix tools — which had by then been used for several CPU-millennia in production environments — actually survived the onslaught of unexpected data. Which simply illustrates the fundamental fact: If you know, or are willing to assume, that your data are clean, you can keep your program much simpler and much faster. If that assumption is not true, your program will not be reliable.

So. Being able to specify, in some formal, machine-checkable way, what constitutes clean data, so that you can make that assertion or assumption true, is a very simple way to allow us to write simpler and faster software.

Now, specifying the rules by a machine-checkable rule is a lot clearer and more concise than specifying them case-by-case in some procedural way. When I was working at the University of Illinois at Chicago’s computer center, I maintained GML macros. The macros for GML checked certain error conditions. The macro for H2 checked that there had been an H1, and the macro for an H3 checked that there had been an H2 since the most recent H1, and so forth. The macro for footnote did not check for any such thing, and there was nothing that I could find in the GML macro set that prevented you from putting several chapters of your dissertation into a footnote [audience laughter] — except, possibly, the Office of Graduate Studies, who would refuse to accept it.

But you really shouldn’t have to rely on the Office of Graduate Studies to ensure that your outputs are clean! Specifying document grammars in a declarative notation was, therefore, a tremendous step forward.

The problem with error messages

On the other hand, that is not our emotional experience. In practice, rules don’t seem to play any important role in making our lives better — we are most often aware of them when they constrain our ability to do things we want to do. When users talk to us about DTDs we have written, they are much more likely to be complaining about something they want to do and cannot do, than they are to be congratulating us for saving them time and effort in writing their software, or for capturing the essence of their problem area so correctly.

Possibly they don’t only complain that the DTD is raising an error; possibly they are contacting us for help in understanding the incomprehensible error message that the parser generates for them. Many years ago at the Stanford Artificial Intelligence Lab they wrote a language called the Stanford Artificial Intelligence Language, or SAIL. The first SAIL compiler is said to have had one error message. If you gave it material that had a syntactic error, the error message said, gently, “This is not a SAIL program.” [audience laughter] Over to you! [audience laughter]

It’s easy to understand why learners of programming languages, like learners of SGML and XML, often resent the syntax error messages that compilers give them. This isn’t new. In the 1960s Ralph Griswold, who was then at Bell Labs, was so irritated with syntax error messages that he spent a year or so designing, specifying, and then implementing a language in which there would be no syntax errors. Every sequence of input characters was a legal program [audience laughter], so there were no errors — and, therefore, no error messages. [audience laughter]

We have some examples of this here (at the conference). I don’t know how many of you were watching your fellow attendees’ faces, to see the horrified reaction that some people had when Jeni Tennison talked about the type-casting rules for XPath 2.0, and especially when she said that she gets typing errors. If Jeni Tennison gets type-system errors when she writes XSL 2.0, what hope can there be for the rest of us? [audience laughter]

And so often the error messages seem to miss the point. Psychologically, the compiler comes across as a chronic kvetch, complaining about every little thing even when it’s perfectly clear what we wanted. “Semicolon expected here.” If you knew you were expecting a semicolon … [huge audience laughter] Passive-aggressive compilers? [audience laughter]

These things give error messages and rule checking a bad name. They give those of us who occasionally admit to a belief that validation is important the reputation of being rigid, prissy, rather priggish. We’re unable to go with the flow. We’re uptight. We’re not cool people, because cool people are not fussed by irrelevant details.

It’s not just mere coolness; there are good engineering reasons for remaining cool in the face of errors. I cite the example of HTML on the World Wide Web, which distinguishes itself from earlier hypertext systems not by providing new methods of preventing link breakage, but by saying, “Yup, links break. Not going to check for them, because nothing you can do will entirely prevent them from breaking and still scale. It’s more important to be scalable.” If you are willing to live with the possibility of error, again your software can be a lot simpler and a lot cheaper, which is one reason that HTML browsers were easier to write and to use than, say, Guide.

The importance of failure modes

The credit card system that we all use has some similar characteristics. I’m sure that there are lots of rules that tend to reduce the incidence of fraud. There could be more stringent rules that would definitely have the effect of reducing the level of fraud still further. Why aren’t they adopted? They aren’t adopted because they would make the system unusable. The point of the credit-card rules is to keep the level of fraud to an acceptable level. You can do the math yourself: you know the surcharge that merchants pay. As long as the fraud is kept to that level, as long as the cost of the fraud is lower than the cost of reducing the fraud, that’s the equilibrium that we see.

So I don’t think that the danger of rules is merely that they can be irritating and that some of our more uptight colleagues may overvalue them. All good engineering must seek not only to avoid or prevent failure but also must plan for failure, and think about the behavior of the system in failure mode.

One of the most important and useful things you can do in failure mode is to recognize that you are in failure mode. The programming language that Ralph Griswold built, in which there are no error messages, is not a programming language you have ever heard of, and there is a good reason for that. It proved very rapidly to be unusable, because the absence of syntax errors did not mean that Griswold was writing perfect programs. It merely meant that the programs were not doing what he intended them to do, and there was no way for the compiler to give him any hint about what the problem was. In the same way, the silent type coercions of XSL 1.0 are mostly a convenience: I want to concatenate a number with a string; well, it’s fairly obvious that I want the number to be coerced to a string using a to-string function. But how many of you have written more than five XSLT stylesheets and never failed to put a second pair of quotation marks around the value of a variable, causing the XSLT processor to interpret what you intended to be a string — and which you put quotation marks around to show that it was a string — as a nodetest, causing output that was not what you intended, but no error message? [audience laughter]

Irritation is not the real problem with error messages. The real danger with rules and following the rules is that you train yourself to think inside the box. Any tool shapes the hand that wields the tool; that is true for intellectual tools as much as for physical tools. It’s not just carpenters with visible callouses who show the deformation professionnelle that marks any trade. As Tim Bray said a few years ago, we’re all of us running around with DTD-shaped holes in our heads. [audience laughter] It’s true. Our systems deal well with certain things, and we focus on doing those things that our systems do well. Our systems deal well with trees, so we are constantly tempted to work with trees, to think of our problems in terms of trees, and to think that overlap isn’t really all that important in our data. That’s understandable. But the constant risk is that we will succeed in persuading ourselves that overlap isn’t important in our data.

Solutions to exercise 22

As you might expect, after the introduction, Knuth gives us two solutions to Exercise 22, reflecting two things that he wants us, pedagogically, to be thinking about.

We are to write two programs to calculate X13, one conserving space and one conserving time. To conserve space, the smallest program is a very tight loop that runs twelve times, that multiplies the value of the register by X. The multiplication operation in MIX simulators is very expensive: to mimimize time, we want to minimize multiplication. To do that, we exploit the fact that you don’t actually have to use 12 multiplications. Multiply X by X to get X2; multiply X2 by itself to get X4; one more squaring operation gives me X8. If I was careful, I have not erased X4, so now I can multiply X8 by X4 to get X12; now multiply that by X to get X13 in 5 multiplications, which is, as Knuth proves in a brief digression in the main text, the minimal number of multiplications.

This is not, however, the best program. The solution part says: Well, if b is the byte size, the assumption that the absolute value of X13 is less than b5 (because a word is 5 bytes) implies that X2 is less than b (in order that X2 can be contained in a single byte), and he gives a solution by Y. N. Patt which makes use of this fact: After calculating X4 in one half of a double-wide register, the solution by Patt loads X into the other half of the double-wide register. The next multiplication by X4 gives you X8 in one of the registers and X5 in the other — so he gets by with four multiplications! [audience laughter] Is that a hack or what? [audience laughter]

I confess I didn’t think of that. [audience laughter] I didn’t even feel bad that I didn’t think of it. [audience laughter] But I did feel bad when I turned the page and read the true minimum time.

“As R. W. Floyd points out, the conditions imply |X| ≤ 6, so the minimum execution time is achieved by referring to a table” in which one word is loaded with the value of -613 and the next with -513 and the next with -413 … all of which can be computed. [more audience laughter]

I don’t know about you, but my reaction then and now is: “But that’s cheating!” [shouts of audience laughter]

My second reaction is: “Yes, that is cheating. And that is the difference between a dutiful student and a great computer scientist. The great computer scientist has no hesitation in cheating!” [shouts of audience laughter]

It reminds me of the scene in Butch Cassidy and the Sundance Kid, in which one of the members of the gang is unhappy with the way things are going and wants to challenge Butch Cassidy to the leadership of the gang. So they agree they’re going to have a knife fight. The big guy — who has at least 2 feet on Paul Newman and probably 150 pounds — strides out with his Bowie knife into the corral for the knife fight. He’s getting himself ready when Butch says, “No, no, hold on there, wait, we can’t start yet. We’ve got to, to clarify the rules.” The big guy says, “RULES? There ain’t no rules in a knife -----.”

That’s about as far as he gets. At least I think so. I never heard the end of the sentence for two reasons. First of all, somewhere in the middle of the words “knife -----” Butch’s boot connects with his crotch, and as he doubles over, Butch cracks his head between two fists and his knee. I don’t think he got the word “fight” out — but even if he had I’d never have heard the word, because every male in the audience groaned so loudly that you couldn’t hear anything from the screen for about two minutes.

There ain’t no rules in a knife fight … And a knife fight is what our struggles with our problems are, or resemble.

Measuring the height of a building

This is illustrated by another well-known story that circulates on the web. I would hesitate to tell it to you again, since everyone’s seen it, except that when I looked on the web to check the details I discovered that there were several web sites where people say, “I don’t understand the point of this story,” or “This makes no sense to me,” and attempt to refute the story point by point. So maybe it’s worth thinking about after all.

The story is almost certainly apocryphal. At the University of Copenhagen, about a hundred years ago, a physics student appealed his grade on an exam. He got a zero. He maintained that the answer was correct and he should not have gotten a zero. The instructor maintained that the answer exhibited no knowledge of physics and, therefore, deserved a zero. They appealed to some great and good physicist, sometimes said to be Sir Ernest Rutherford, although what he was doing in Copenhagen I don’t know.

The question was: Explain how to measure the height of a building using a barometer.

The student had written:

  1. Go to the top of the building with a barometer and a long string.
  2. Tie the string to the barometer and lower it over the side of the building. When it touches the ground, mark the spot, measure the string, add the height of the barometer, and that’s the height of the building.
[shouts of audience laughter]

I submit to you that this is a correct answer; yet the instructor was right: this doesn’t actually tell you much about the physics the instructor was trying to test.

The adjudicator said as much to the student, and asked, “Do you have any other answers that exhibit more knowledge of physics?”

“Oh, yes,” the student said. “Take a stopwatch. Drop the barometer over the side of the building. Listen for the impact; time it. Plug it into this equation. Check the precision: if the precision is not sufficient, then use the estimated height to correct for the speed of sound being non-instantaneous, and make that adjustment. [shouts of audience laughter]

“Second, you can scale the building, marking barometer lengths, and multiply by the height of the barometer. [audience laughter]

“Measurement adjustment is an important part of physics.

“Take a spring scale (you have to have a good spring scale for this method). Measure the weight of the barometer at ground level, go to the top, weigh it again, calculate the difference in measured weight for the same mass, and put it into this equation.

“Or measure the barometric pressure and put it into this other equation … but that’s not very interesting … [shouts of audience laughter]

“Probably the best way, though, is to go to the basement, knock on the superintendent’s door, and say, ‘My dear sir, would you like this barometer? I’ll give it to you if you tell me how high the building is.’” [howls of audience laughter]

The part of this story that is almost certainly apocryphal is the association of the student with Niels Bohr. Not because the student doesn’t show the kind of imagination and ingeniousness that Bohr had, but because Bohr was a theorist, not an experimentalist.

But this is what experimental physics is like. If you are doing an experiment in experimental physics, and you have equipment that was designed to do the measurement that you wish to take, it’s almost certainly not publishable because someone’s already done it. If you want to be doing physics that is publishable, you will (at least sometimes) be taking measurements that no one has ever thought of taking before. That means you are going to have to be letting barometers over the side of the building with strings, because there’s no other way to do it.

There ain’t no rules in a knife fight …

Fundamental rules and constitutive rules

The mathematician Paul Erdös was fond of saying, “Problems worthy of attack prove their worth by fighting back.” [audience laughter] Mother Nature doesn’t fight fair; why should you? You want to have every advantage you can: every handhold you can get, on some problems, is a handhold you should take advantage of.

Rule-think can prevent us from finding those handholds.

That’s one reason it’s useful to entertain proposals to extend existing practice beyond its current bounds. I think, for example, of Steve Cassidy’s extensions to XPath, which may or may not be the right thing for linguistic annotation but are definitely important for all those of us who are working with non-tree data structures for documents. LMNL or TexMecs or Just-In-Time Trees need something like the graph-theory expressions that Steve was talking about. Or — one of my favorite examples from this conference — Dmitre Novatchev’s demonstration that even if the designers of the language didn’t think they were writing a fully functional language, they could be wrong: if you hold your fist on the throat of the language just right [gesture provokes great audience laughter], it will do exactly what you tell it to do.

It’s worth noting, perhaps, that all of the stories I just told don’t actually show that there are no rules. There are rules — they’re just not ones a naive interpretation of the situation made us think you needed to worry about. Reality, whether it’s mathematical reality or physical reality or physiological reality, wrote the rules which govern Exercise 22 and the talk of measuring building height with barometers, just as physical reality provides many of the rules which govern chemical behavior and, thus, need to be reflected in the rules for chemical markup, as we heard the other day. Not all rules are imposed by arbitrary and priggish compilers or control freaks. Some of them are imposed by reality.

There are other rules as well. Some rules are neither arbitrary and to be frequently violated in order to avoid getting ourselves into boxes, nor imposed by reality; some of them constitute the activity that they describe. There’s no physical law that says chess moves have to follow the rules of chess; but if you don’t follow those rules, you’re not playing chess. There’s nothing that says you have to play chess; but there are rules that say if you play chess it has to be this way; otherwise it’s not chess, it’s something else. There’s nothing necessarily wrong with that; it depends on what you want to do. If you want to write a sonnet, I can tell you in advance: it will have fourteen lines. If it doesn’t have fourteen lines, it’s not a sonnet, at least not in my interpretive community.

Many of the constitutive rules for activities that are of cultural interest are not written down. Therefore, they’re subject to interpretation and to change that in some ways resembles the rules that govern language change, at least according to some theories of historical linguistics. The rules for sonatas that governed the activity of Haydn are not quite the same as the rules for sonatas that you see if you listen to late Beethoven. It’s not clear to me that Haydn would recognize some late-Beethoven sonatas as sonatas. He might say, “That’s an interesting, ah, form; what’s that?” The rules are not necessarily rigid — although I don’t think chess has changed in a long time.

Another good example of a constitutive set of rules is etiquette. As Judith Martin is fond of pointing out, the goal of etiquette is not necessarily to require that everyone be polite to everyone else; it’s to allow us to tell the difference. If you want to snub someone, you cannot do so in the absence of rules of etiquette. It is impossible to snub someone if they don’t know what you are doing. [audience laughter] These are rules that don’t constrain our freedom of activity, but define our activity, providing new ways in which we can act. They, therefore, differ from rules that are imposed by reality. We don’t need an FBI or a document model to ensure that an algorithm that runs twice as fast will execute in half the time.

There’s a big difference between wholly arbitrary rules or constitutive rules, on the one hand, and fundamental rules on the other, that I think is illustrated nicely, at least for those of us whose memories go back to the mid-1970s. After the oil shortage of the mid-1970s, the US imposed a 55 mph speed limit. After a few years people started ignoring the speed limit, and police departments in various jurisdictions all around the country put up billboards trying to remind people that 55 mph was still in force, and trying to encourage people to take the speed limit seriously. The difference between rules like that and rules that we will follow whether we like them or not was satirized in a T-shirt that a friend of mine bought at the American Physical Society. It said: “186,282 miles per second — it’s not just a good idea. It’s the law.” [shouts of audience laughter]

The rules of XML

So what kind of rules does XML have?

Well, there’s another kind of rule that we need to distinguish. It shares some characteristics with the purely arbitrary conventions that we’ve talked about; it shares some characteristics with the rules that constitute a game; and it shares some characteristics with the rules that come from underlying reality. The closest analogy I can think of is the sort of formalist view of mathematics and logic. It’s particularly visible in the mathematics of the last 130 years and logic in the 20th century; but even before that, the development of algebra, and the development of syllogistics in the middle ages, show the force of this idea.

David Hilbert wrote a book about geometry, and what is said to be interesting about Hilbert’s geometry is that he is the first mathematician to write about geometry who makes no attempt to define point, line, or plane other than by stating the relations that must follow between them. He was fond of saying, “At any point you have to be ready to substitute the words beer stein, bench, and table.” As long as the relations are preserved, everything else will follow. He reduced geometry to what is frequently described as an empty game with meaningless symbols. There are various arcane rules that we follow in pushing symbols around; they line up at the bottom of the page, and we have either proved the theorem, or we have not proved the theorem.

The rules feel arbitrary, and in some ways they are. But in other ways they’re not. The seven axioms with which the Principia Mathematica set out to build all of mathematics and logic have a kind of ragtag look about them: they look kind of accidental. But they aren’t just any seven axioms. You cannot take randomly generated axioms and deduce a theory and expect people to be as excited about your book as they were about Russell and Whitehead’s. Similarly, the rules of inference that are allowed by natural deduction systems and other logical systems invariably feel really astonishingly arbitrary and accidental, at least to me. I’m not a philosopher, I’m not really a logician, so they don’t care how it seems to me. They look very arbitrary, and the expositon that they are given by philosophers doesn’t usually help because they don’t often bother to say, “Of course, these rules are carefully constructed so that, if we follow them, truth and implication are preserved.”

That’s a really important proviso that tends to be buried fairly deep. The rules are very carefully chosen so that, without thinking about the contours of the underlying reality, we nevertheless respect the constraints imposed by the underlying reality.

This is a method of controlling complexity. It works for mathematicians and logicians, and it works for us. If we can follow purely mechanical rules of validation, we can — if we have written the DTD right — end up with clean data, and, therefore, cheaper software, and, therefore, lower prices and higher profits, and, therefore, we all get to keep our jobs. Everyone is happy all the way around.

Tradeoffs

XML seems to me to be one of this special kinds of sets of rules. There are some rules of XML that not only feel, but are completely arbitrary. There’s nothing magic about having angle brackets instead of round brackets, except the network effect: the fact that if you use angle brackets there is a lot of software you can use off the shelf. Whereas the rule that says, “If you mark up your data to a specific application, you’re going to tie your data to that application, and, therefore, your data are going to be old and out of date as soon as that application is changed” is a rule that comes from the underlying reality.

It’s an interesting fact that the game we are playing — or the game we are constructing with our rules of XML — has fairly intricate tradeoffs among:

  • our understanding of the shape of the underlying reality (especially the parts of the underlying reality that we’re trying to model),
  • the actual shape of the underlying reality, which can affect us whether we understand it or not (that’s one of the defining features of reality), and
  • what we know how to do efficiently and describe clearly. There may be many things we know we would like to be able to model, but which we don’t know how to model efficiently, and which we, therefore, leave out of our languages.

The tradeoff is tricky, and it’s important because these special rules — like logic and like mathematics — have their special character only if they’re formulated correctly. If R. W. Floyd were a consultant and he had solved Exercise 22 for a client, and then it turned out that the client had simply forgotten to say that he wanted the solution to generalize, then Floyd would not have had a better solution: he would have had a non-solution, because Floyd had taken the rules at face value and had ignored the fundamental rule, which is that what you really need to do is solve the problem the client really has, which is not necessarily the problem that the client thinks the client has.

Librarians are familiar with this. One of the first things you learn when you study “Reference Service” is the thing I was taught to call “question negotiation.” You don’t take at face value what the patron says, because by and large the patron is lying to you. They say they want to know X; that’s not what they want to know. They think that if they learn X, they will be able to figure out what they want to know. You need to dig a little bit and make them tell you what they really want to know, because quite often they are wrong: once they know X, they’re still not going to know what they really want to know. You’ll find them wandering sheepishly around the reference room, still looking for it but ashamed to go back to the desk and ask again because they know that you will know that they didn’t know what they were talking about. [audience laughter]

Limits

Among the fundamental rules that we have to respect because I think they’re imposed by reality are that if we want our data to survive a while we have to free it from application dependency. One reason that I think it’s plausible that this is a fundamental rule and not an arbitrary decree of the XML 1.0 Working Group is that relational database systems rest on exactly the same observations. One way to do this — not necessarily the only way — is to describe not what you want to do to something, but rather what that something is. One way, perhaps the only way, to describe what that something is, is to understand it correctly, or what Jim Mason did not quite refer to the other day as “its one true name.”

But at the level we’re working, there’s no guarantee that things have a single true nature or true name. Like Steve Newcomb, I think it’s worthwhile trying to find it, or trying to find a way to work around the fact that we don’t necessarily have it; but like Bill Kent, some of us remain sceptical about the chances of success even while agreeing that it’s worth trying.

At the level we’re working, different people will have different understandings of the reality we’re modeling. There will be no single application and, therefore, no single approach that we can use; and so, with apologies to Neill Kipp and Sam Hunting, I’m sorry to say there will also be no one programming language. Even the very simple rule “Look at the data in different ways, to help you understand it,” as illustrated by David Birnbaum’s dendrograms and plectograms the other day, remains crucial.

Finally, our grasp on reality is necessarily partial. Even if we managed to model our understandings of reality completely, which I also think is unlikely, our models of reality would necessarily remain partial because our grasp on reality is partial. Validation is important because it gives some bite to the ability of a user to describe reality as the user sees it. If you don’t have validation rules or the moral equivalent, the claim that a user can be modeling reality is just hand-waving for which no one can be held responsible or will be held responsible because the XML processor has no way of saying, “But that is inconsistent with what you told me over here.” Our claims about the reality we’re modeling will have no consequences. Validation will give them some consequences.

I agree fully with Tommie (Usdin) that it is these rules, this end of the spectrum, the bits of our practice that model those underlying bits of reality, that are important, and not the angle brackets. The angle brackets are only a means to an end, and they, unlike the others, are simply rules that we make. There are rules about the gravity of information — the natural laws of information — which are rules that we didn’t make, we discovered. That may explain why they’re not nearly so well documented. Rules that we make are made by some working group, and that working group is responsible for documenting them. Rules we discover are not the responsibility of an individual working group, and it is not a group’s responsibility to document them. Working groups don’t necessarily agree on what, exactly, the underlying rules are, and they don’t necessarily have to agree in order to fulfill their charters, so they may not document them for that reason. And some of us may have the view that it’s not really important. I know there’s gravity, but you know, if I don’t publish a paper on it, it will still work. [audience laughter]

The true and the useful

Whether we document these underlying rules or not, the game we’re playing as an industry is to build systems which must navigate this tricky course between being true and being useful. Ideally, we build systems that are both. As a general engineering principle, if you make your system reflect reality, you’ll have a system that works better; but sometimes we don’t have a good enough understanding of reality to agree on what’s true, and we can settle for something that’s just useful.

The other night, in a discussion, several people agreed that the notion of a “work” in the FRBR model that Allen Renear and the other students talked about has no plausible claim to reality. No one in the room could agree that something like the FRBR “work” could exist. On the other hand, everyone agreed that it was very useful to behave as if we thought it did. We can build it into systems that are useful, as long as we don’t confuse them with being true.

Sometimes the correct engineering tradeoff is to hold out for the truth, because we think we can reach it and because it’s almost always better engineering to do so. And sometimes the correct engineering tradeoff is to settle for the useful, because truth in a particular domain may be so elusive. Two different kinds of rules; two different kinds of design. It’s a good idea to try not to confuse them.

It would be handy to have a rule that allowed us to distinguish reliably and mechanically between the two. But we can’t. Because there ain’t no rules in this knife fight.


Playing by the rules

C. M. Sperberg-McQueen [World Wide Web Consortium]
cmsmcq@w3.org