BridgeML and PBN

I'm working on a Perl program to convert PBN files to BridgeML. It works by first converting the file to an intermediate XML format, then uses XSL to do the final conversion. The tricky parts are the "exceptions," like when a bid or play is made out of turn.

One source of irritation is the way that the play of the hand is formatted in PBN. The file might look like:

    ...
[Dealer "N"]
[Vulnerable "None"]
[Deal "N:A9863.KQ987.K8.T KJ2.J.AJ9.AK9865 754.A2.QT752.732 QT.T6543.643.QJ4"]
[Contract "5CX"]
[Declarer "E"]
[Result "10"]
[Score "NS 100"]
[Auction "N"]
1S      2C      2S      3C
3H      5C      X       Pass
Pass    Pass    
[Play "S"]
C2 CQ CT C5 
S4 SQ SA S2 
D7 D3 DK DA 
S5 ST S3 SK 
S7 D4 S6 SJ 
DT D6 D8 D9 
*

Note that the play of the hand is listed in such a way that all of South's plays are in the left column. What is the purpose of this convention? Part of PBN's purported advantage is ease of reading and writing, but this convention is unnatural and unreadable. Just a guess, but I suspect this method was chosen to make eye-balling the play for correctness easier - specifically, making sure each hand has the cards it is purported to have played.

The problem is, you have no way of knowing who won a trick, or the sequence of play, unless you know the contract - the "Play" section does not stand alone. Why does the Play tag include the opening leader, which only affects the first trick, and not the trump suit, which affects the entire play? Either piece of data can be determined from the contract and declarer.

Any software program trying to reconstruct the sequence of play needs to refer to the external entity - the "Contract" or "Auction" sections - and then needs to apply the entirety of bridge card play logic for the play of the hand to reconstruct the actual sequence of cards played.

In addition, any program writing the PBN file necessarily cannot write anything until a complete trick is quitted, which keeps information in memory. Now what if the program crashed? It loses that internal information, and play can only resume from the beginning of the trick.

A similar logical problem in PBN is that the Contract comes before the Auction, so that a program recording play cannot write the auction until it is completed - it must keep internal state in memory. Again, if the program crashes, it loses the auction information and must start from scratch.

The play of a bridge hand is a narrative. Our record of the play of a bridge hand should represent the sequence of events in the play. That means that sequence of information should be:

Event information - event, location, scoring, etc.
Board information - dealer, vulnerability, board id/number
Cards - the actual deal.
The round this record represents, including perhaps table number.
The players.
The auction - if available.
The contract and declarer - not 100% necessary if the auction is available, but good form so that software reading doesn't have to parse the auction if it only wants to know the contract.
The play of the cards in sequence - if available
The result - as with the contract and declarer, not 100% necessary if full play of 13 tricks is recorded, but should be included to avoid requiring the parser to read the play to determine result.
The score.

The record of the play of a hand is implicitly a narrative - a sequence of events. It should not require the reader to skip forward and back. When a notable event happens during play, the software recording the play should be able to write out the "notable event" immediately.

PBN can fix the narrative gripes fairly easily by making the "Play" section indicate the trump suit (or 'N' for notrump,) add lead information to each trick, and write the card plays in order. You could also put the "Auction" before the "Contract," and the results after the "Play" and you get something very similar but much more natural:

    ...
[Dealer "N"]
[Vulnerable "None"]
[Deal "N:A9863.KQ987.K8.T KJ2.J.AJ9.AK9865 754.A2.QT752.732 QT.T6543.643.QJ4"]
[Auction "N"]
1S      2C      2S      3C
3H      5C      X       Pass
Pass    Pass
[Contract "5CX"]
[Declarer "E"]
[Play "C"]
S: C2 CQ CT C5
W: SQ SA S2 S4 
N: DK DA D7 D3
E: SK S5 ST S3
E: SJ S7 D4 S6
E: D6 D8 D9 DT
*
[Result "10"]
[Score "NS 100"]

If you want to make the left column always be the south card, you can alter the play:

[Play "C"]
S: C2 CQ CT C5
W:    SQ SA S2 
   S4 
N:       DK DA
   D7 D3
E:          SK
   S5 ST S3
E:          SJ
   S7 D4 S6
E:          D6
   D8 D9 DT
*

Now the PBN file is a narrative of the events. Any program capable interpreting this section would not even need to know it was the play of a bridge hand. It could be any trick-taking game - Whist, for example. The section stands alone; it allows re-use and flexibility. It's win-win - easier to generate, easier to read, easier to parse. It's very slightly more verbose, and, yes, the "optional" sections of the PBN file are mixed with the "required" tags. But any parser which gets befuddled by that is a bit silly.

Fundamentally, the problem in PBN is the flatness of the presentation, and the inflexibility of the sequence of tags. Is there really a shortage of easy code to handle un-ordered information - does a person writing a parser for PBN really have trouble stuffing information in a hash table? And, when order actually matters in some logical sense, PBN violates the simple logic of a narrative. Why is the play of the hand out of sequence? Why is the Contract before the Auction? The Result before the Play? It is illogical in the extreme. Any program trying to present the file as a narrative needs to actually know quite a bit about the rules of the play of the hand to untwist the "Play" section.