XML - convention cards, etc

[rich_wil]

Bridge Bidding Systems

 

These observations arise out of my efforts to update and enter a Precision bidding system for use on BBO.

Bidedit.exe

I have very seldom seen the current convention card function used in play. I think there are very good reasons for the resistance to the adoption of this new feature.

 

Problems

The present bid editor has a number of difficulties:

1. The data must be fully and explicitly entered for every branch and node. There are no facilities to make general statements about a class of things i.e.. over all major suit openings, all minor suit raises, etc. Thus it is very tedious and time consuming to enter what may be very redundant values for every node.

2. Error checking is extremely difficult, as the editor does not provide a view of the entire tree structure. Thus each individual limb must be explored and all of the data in it checked branch by branch, node by node.

3. It does not provide a convenient overview for reviewing bidding agreements with prospective partners.

4. It is subject to random change (i.e. lacks version control for included convention files).

5. Cannot be used to describe defensive bidding if it is used against more than one set of opponents. The starting point of a defensive bidding sequence is a bid by opponents. The branches from that bid must be changed if new opponents have different meaning assigned to the opening bids. i.e.:

I. For a 1NT meaning 15-17 hcp, you fully describe DONT but the next opponents play 1 NT as 12-14 hcp and you use Cap vs. weak NT. A third card would be needed if 1 NT’s strength varied with vulnerability.

II. A Double of 2C could show a weak hand with the majors against a strong 2C opening but be an intermediate to strong three suited takeout against a precision 2C bid.

Each change in opponents bidding system requires a new card.

Characteristics of desired solution

What would be nice is a consistent way to exchange descriptions of bidding systems over the Internet. Ideally, the same system description should be available in a tool to assist partnership discussion and system agreement. It should facilitate disclosure to opponents both prior to commencement of play and during the auction. It should also be accessible to a number of editors and communicate with the software of various tournament organizers and national Bridge bodies. Multiple applications should be able to import and export the data including the common bridge playing programs – Bridge Baron, etc. Both online and real world tournament organizers should be able to use it. Bridge broadcasters should be able to easily and automatically import convention card data into their system.

 

Solution:

There is a tool that is designed specifically for exchanging structured information of this type over the Internet -- XML. It may be well worth the effort to create a bridge bidding system style sheet or template.

 

Editing XML

There exist many XML editors including a number of good freeware ones. Some of these are optimized for tree data structures. One of these, with a bridge style sheet, would be ideal for entering or reviewing systems. It may be possible to avoid the time and resources required developing a specialized editor from scratch.

[barmar]

None of the problems you mention would be solved by using XML for the CC files. XML is a file format specification, but it doesn't address the logic of the applications that use the data. And all those problems are with the logic of Full Disclosure.

 

Another issue is that the FD file format was deliberately designed to be terse, and XML is a pretty verbose file format. Many BBO users have poor, slow Internet connections, and anything that minimizes the amount of data that has to be downloaded is important.

[scoob]

http://www.tistis.nl/bbn/index.htm

[rich_wil]

>"Scco:

bhttp://www.tistis.nl/bbn/index.htm"

 

Sccob, thank you for posting a site offering a bridge bidding systems editor which has been implemented using this technology.

 

>"Barmr -

None of the problems you mention would be solved by using XML for the CC files. XML is a file format specification, but it doesn't address the logic of the applications that use the data. And all those problems are with the logic of Full Disclosure."

 

Barmar, thank you very much for replying to my post.

 

xml is a method of transferring data between applications in a very flexible but standard way. It also has a suite of standard tools and extensions for transforming that data into other forms including the type of operations required to replace a single bidding tree for "Majors" with two trees "Hearts" & "Spades" with appropriate substitutions for "other major" or "raise".

 

The logic required for ease of implementation on the playing server should not dictate the design of the editor & user interface.

 

"Barmar -

Another issue is that the FD file format was deliberately designed to be terse, and XML is a pretty verbose file format. Many BBO users have poor, slow Internet connections, and anything that minimizes the amount of data that has to be downloaded is important. "

 

That issue should have nothing to do with this. If the data is stored at both ends, it may need to be synchronized no more than once or twice a month and posibbly as low as every six months?

 

The question of minimizing the data exchange at sign on is a very important but seperate topic. The main problem with the current system is uploading/downloading information that is not required. This might be greatly reduced by the following:

1. storing all user preferences on the server and on the client with a synchronization/version code.

2. downloading only the information on users that would be immediately displayed.

- in the lobby, only those online members on the users display preferrences

- at a table, only the other three players

- on viewgraph, only the commentators/hosts

- downloading the table information only if the user wishes to view it