XML Bridge Tests Calls and Contracts >>

Introduction

This set of documents shows what the inputs and outputs look like in my XML/XSL/CSS documents.
The XSL processing converts the documents to HTML - this amounts to creating tables for hand diagrams and auctions, converting codes like "2H" to 2 , deciding whether to put white-spaces in holdings, etc. The resulting HTML generated has plenty of class attributes added to the <div>, <p>, and <span> tags which makes additional formatting customization via Cascading Style Sheets (CSS) possible. These documents are using my article.css. Most issues like font sizes, colors and backgrounds are left to the CSS. I could, for example, make the diamond and heart symbols black with a simple change to the CSS.
Many of the formatting decisions I've made are based on the recommendations in Richard Pavlicek's Bridge Writing Style Guide. The goal is to make the input XML document simple, human-writable and readable, and use the XSL to enforce the output standard where possible. So, while the input documents use T for the 10-spot, the XSL writes out "10." And while the input has no spaces between cards in holdings, as in QT654, the XSL prints Q-10-6-5-4 in paragraph contexts - seperating cards with spaces in diagrams ala:
A K Q
J 10 9 8 7
6 5 4 3 2
 
10 9 8
A K Q
J 7
6 5 4 3 2
Other style decisions I made on my own. For example, when red suit symbols occur in paragraphs, I've chosen to make them slightly darker than the red that occurs in diagrams because I find that the bright red in the middle of paragraphs interrupts the "flow" to the eye. This can be adjusted in the Cascading Style Sheet easily. The color I've settled on is 20% darker than pure red.
Style sheets for auction tables still do not handle one-sided auctions - I'd like the <auction> tag to take an attribute which flags the auction as one-sided (not necessarily uncontested, but perhaps with only a few bids.)
The goal is for the XML to represent possible bridge events, and have the XSL do transformations for presentation purposes. So the writer would write three passes rather than "All Pass." If the XSL formatter finds a situation where "All Pass" is an appropriate substitution, it can make the substitution. Note, not all instances if three passes, or even four passes, represent the end of an auction, if there has been a pass out of turn. This makes the XSL somewhat complicated.

Terms

These definitions may seem pedantic, but sometimes the words are used less precisely.
Seat
One of the seats in an auction or card diagram. When in an XML 'seat' attribute, it can be one of 'E', 'W', 'N', or 'S'. For example, <call seat='W' code='2S'/>. In the middle of an auction with no dealer seat specified, the seat can be one of 'dealer', 'LHO', 'partner', or 'RHO.'
Hand
References the cards being held by a particular player. This can be either 13 cards at the start of a deal, or some lesser number, representing a later state in the play.
Deal
A deal is distribution of 52 cards to four hands in each seat.
Board
A board is a deal in the context of a competition - information like the dealer, vulnerability, partscore (in rubber bridge), etc.
Play Record
The details of a played board - might include players, auction, contract, cards played.

Download

You can download the XML and XSL [1.7Mb] which is used to generate my bridge articles, including these test documents. This zip file includes the Java class files fo Xalan-Java 2. You need Java 1.2 or 1.3 installed to use the XSL scripts.
Thomas Andrews (bridge@thomasoandrews.com), © 2002-2009.
Calls and Contracts >>
Article formatted with BridgeML.