Bridge Notations

Some notes on a couple of projects which exercise my mind from time to time.

Bidding Systems Notation

I have had under consideration for some time now the question of codifying Bridge bidding systems, in such a way as to make them available to a Bridge playing program. Although there are a number of Bridge playing programs which allow you to choose between several basic systems, and embelish them with your choice from a variety of optional conventions, so far as I am aware there is no program at present which will play a system entirely of your own making. To create such a program would require a notation, which could be used to define your chosen system in its entirety, and which would be comprehensible to a program (if recorded in machine-readable form, of course). That is the primary objective of this project.

I don't really have much of this in place yet, but I am convinced that, to be really useful, such a notation should have these characteristics:

• It should incorporate inheritance, in the OOP (Object Oriented Programming) sense.
• It should be text-based (i.e. no binary data, just ASCII or Unicode etc.) and most likely should be expressed as an XML DTD or XML Schema.

The Need for Inheritance

I can't see that it would be really practical to completely define every system from taws. I haven't tried to calculate the total number of bidding sequences that would be required to describe a bidding system in its entirety, but it must be enormous. As well as all the uncontested auctions, you need to consider intervening bids at each stage of the auction, plus the effects of any intervention earlier in the auction.

Since every bidding system shares certain characteristics with other bidding systems, it seems only logical to create a new system by taking an existing system as a base, and describing just the differences. This is probably the thought process that goes into the creation of most new systems, and it would make sense to extend the process to the encoding of the new system.

File Format Considerations

Unlike most of the world, it seems, I don't normally do my computing on a Micrsoft platform. That leads one to a view of things which can have quite a different slant from those computer users who are blissfully unaware that there are operating systems whose names don't start with "Windows", and there are other ways of publishing documents than Microsoft Word.

I am excited by the promise of XML. XML files should be equally readable and useable on Windows, Macintosh, Linux, Unix, or any other operating system and hardware platform (except perhaps some obsolete ones). XML is equally capable of carrying relatively unstructured text, such as web pages or wordprocessing documents, or highly structured data, such as business transactions. XML can be manipulated by a range of interchangeable utility software. There are a number of parsers, XSLT translators, etc. available right now, for just about any platform. As browsers, print engines, and so on, get more XML-capable, we will finally have a genuine, widely supported platform-independent medium.

XML seems like the right medium for a bidding system notation.

Hand Notation

Some other recent projects have lead me to also consider how to codify Bridge hands. Actually, I mean hand plus auction. (Is there an official term for this?) I am aware that there is at least one system in existence already to do this (PBN - Tis Veugen's Portable Bridge Notation ), but PBN doesn't do quite what I wanted.

Actually, I came to this project through wanting a replacement for Jeff Goldsmith's LaTeX Bridge macros . I have quite a bit of Bridge documentation stored in LaTeX and Lyx files. I started to convert one of these documents to docbook-XML. It didn't take me long to realise that docbook has no facility for formatting Bridge hands. In my Lyx and LaTeX documents, I had used Jeff's macros.

I am still learning XML & XSL, but I believe I can achieve what I want by creating a new DTD and a new XSL stylesheet, to handle the Bridge hands, and merging those with the docbook files. I haven't done it yet, but I think it's feasible. That would be immensely preferable to creating a modified version of docbook (bridgebook?).

And then it occurred to me that this DTD would be useful in other contexts. In fact, if carefully done it could be the only format needed for encoding Bridge hands. Hands encoded in this way could be typeset, published in web pages, loaded into Bridge-playing programs, loaded into dealing machines, and anything else that I could imagine that you might want to do with an encoded Bridge hand.

Thanks to some assistance and encouragement from Torbjörn Gannholm, my earliest crude efforts are gradually evolving into something half presentable.

Torbjörn has suggested some changes to the files below. I didn't have time to incorporate them this time round, but they will probably appear in the next round of changes.

Here is a sample XML file, as an example of what I have in mind. (If your browser understands XML, it will probably strip the markup from the XML file. You can see the marked-up file by clicking here. (This will apply to Netscape 6.0 or later, IE 5 or later, Mozilla 0.7 or later, or Opera 5.0 or later.)) And here is a DTD to go with it. I have started on an XSL stylesheet to transform the XML into HTML.

Here is the result of applying this XSL stylesheet to the above XML file with Xalan XSLT engine. (Recent browsers will lose most of the XSL stylesheet, in the same way as they lose most of the XML. Here is an alternative showing the markup.) This is not a very robust stylesheet. It works reasonably well with this example file, but I wouldn't expect it to work with any file valid to the DTD. It should.

Here is an earlier attempt: XML file, marked-up file, DTD, generated html, and XSL stylesheet. This is not a very robust stylesheet. It works reasonably well with this example file, but I wouldn't expect it to work with any file valid to the DTD. It should.

I will be attempting several other XSL style sheets. I am not sure whether I should bother with CSS sheets as well.

These are very early versions, and will probably change considerably before I consider a general "release". In particular, I want to see what elements are in PBM that I ought to consider incorporating.

It is possible, of course, that someone else has had similar ideas. I would appreciate being advised, if anyone knows of such a scheme, either already in existence or under development. I would be happy to support or collaborate on someone else's project, if it is likely to produce a better result than I can achieve alone. (As I said above, I am in the throes of learning about XML & XSL.)

Since I started this, I have discovered Glen Ashton's Bridge Matters site, which has a page discussing XML and Bridge, including links to some items from a newsgroup discussion on the subject.

And so that is where I am currently headed. As things emerge, I will post more details here, for review.

Next Steps

1. Rework the DTD to be more closely aligned with PBN.
2. Expand the DTD to include play, result, score etc.
3. Fix some wrinkles in the existing (XML to HTML) XSL stylesheet.
4. Create a stylesheet to output Formatting Objects, and produce PDF files via FOP.
5. Get back to my original objective - create something which can be used in conjunction with "docbook".
6. (Perhaps) create a Schema, as an alternative to the DTD.

XML vs PBN

Why not utilise the existing standard, and just build tools to translate PBN files into whatever form we need?

PBN is obviously widely accepted as a defacto standard. It has some attractive features, and wide support. But it has some limitations, too.

• PBN requires purpose-built tools to apply it. General purpose XML tools and utilities are available off the shelf. Obviously no XML utility program will play Bridge, but general purpose utilities are sufficient to produce pretty formatted documents, in say PDF format.
• PBN limits the length of a line to 255 characters. This is not likely to be a practical problem, but XML is not line-oriented, and so has no such limits.
• PBN files cannot be "included" or "called" meaningfully from other files, without special processing. XML files can be linked into other XML files, and perhaps other file formats too. (From my selfish perspective, that means that there is no way to include PBN files directly in my document collections.) An XML file may be a (re-useable) fragment of a larger work.
• One of the objectives of PBN is that it be readable as raw ASCII, with no formatting. Well laid out PBN files are in fact quite easy to read. Well-structured XML (with tags and line breaks positioned for readability) should be at least as intelligible, although that depends to some extent on the descriptive nature of XML tags and structure, whereas PBN achieves its readability through layout, and the reader's ability to infer meaning from the layout, rather than some of the less descriptive tags.
• You cannot extend PBN (to add new features, say) without creating something which is no longer PBN. XML is an extensible standard, and it would be quite feasible to extend any given DTD without making the resultant file unuseable to other users. PBN does prescribe some conditions which aid compatibility between different PBN versions, but does not appear to be any specification for user-defined extensions. (Tis Veugen says that they are available - programs are supposed to ignore unrecognised tags.)

XML has a growing momentum. I believe it is inevitable that some people will start to use XML in preference to PBN (as they are already doing in preference to a number of other standards), and that an XML standard for Bridge will eventually emerge, whether we like it or not. I have no existing investment in PBN, so I want to be in on the ground floor with XML.

Miscellanea

As an example of some of the XML tools around here is a screenshot of Merlot XML modeller with the example XML file above loaded.

And here is a screenshot of IBM XSL Editor with the example XML and XSL files above loaded. (Unfortunately I am not able to use this editor at present, since it requires JDK 1.1, which I no longer have.)

Here are some examples of the sort of documents I eventually want to work with (unfortunately without the Bridge capabilities, yet).

• The main file for a small book. This contains links to include the component chapters etc.
• The component files for the book.
  • The preamble.
  • The abstract.
  • Chapter 1.
  • Chapter 2.
  • The appendix.
  • The bibliography.
• The HTML produced from the above files. This was produced using Xalan, Xerces, and Norman Walsh's docbook stylesheets.
• A PDF file produced from the above files. This was produced using Xalan Xerces, FOP, and Norman Walsh's docbook stylesheets . There are some problems with this conversion. It would appear that either fop or the stylesheets are not handling tables as you would expect. I am investigating this problem. In the meantime, this should give some idea of what we can expect when everything is sorted out.