Poker Hand XML - Page 14

MuppetBingo · #**131** 08-02-2007, 01:55 PM

@ShoeLace

We could make an open source application, the universal hand-history converter which monitors a set of directories for new hand-history files, with plugins for each different site. But that's a different task than creating the poker hand xml schema. When a converter for a specific site fails (if we can detect that somehow),it notify the main for our application that site-x has changed their format, so people are aware that it's broken and automatically when someone uploads a new converter, everybody would get the new one. There are loads of other ideas I'm sure.

It might be a good idea to make a tool like that, for the sake of general acceptance of the XMl format, but that's for a different thread I think.

@ThirdEye

Making a common DB is also a seperate goal and one I think will fail because different apps have different
needs for a balance between normalization and performance optimization (as Phil152 said), and some applications
might not even need a DB at all, but would work just as well on a set of xml-files (ie. the sklansky bucks calculator)

You could however very easily use the xml-definition as a starting point to create a normalized db-schema.

@TSchauenberg

Good input, thanks!

[ QUOTE ]
optional summary at end listed for each player and have enough useful data that only that section need be read for lots of apps. For example, listing a player's net values, their last seen stage, and their hand would make it very easy for people to write graphing programs, leaderboard programs, equity output programs, etc. without having to parse the whole hand

[/ QUOTE ]

I am in the camp that thinks this format should be as simple as possible (but no simpler). I think the handhistory
converters should do as few calculations as possible.

The xml should be somewhere in the middle between hand-history readers and 2+2 format outputters. It should make
both jobs as easy as possible.

@Erastosthenes

"1) The sites' put a textual description of the hand in the HH: "Flush A high." If that is in the HH, it should be in the XML file because it saves the site's evaluation of the hand."

Hmm, maybe as an optional attribute on the winning hand.

"2) Muppet's idea of rounds with cards and actions associated with each round is great. The rounds should be numbered and named. The number is the order in which the rounds are played. The name is what the site calls that round in its HH. This avoids confusion between "Turn" and "Fourth Street"."

The program that converts the input from a site's hand history into this xml format, is meant to convert whatever term
the site uses into a set of specific round-type attributes. The possible values for this attribute could be a number, or
it could be "flop, turn, river" for texas games. Either way it clearly defines which round goes before which, (if you know
the semantics of the words "flop", "turn" and "river").

There's no need to preserve whatever name the site gives the different streets imho.

@All
We should definitely try to get PokerTracker onto the bandwagon, and the sklanskybucks calculator.

Points that is still very much open for debate (there are others too I am sure):

* Card value attributes <cards value="Ac Ah"/> vs. <card value="Ac"> vs. <card value="A" suit="c"/>. Often when a decision
is very close either way, it takes a long time to decide which one to use. I feel that we may have such a case here, as
I certainly don't have strong feelings either way, but I am somewhat reluctant to do the opposite of what OrcaDK says,
since he seems to know what he's talking about :-).

btw. I looked into xsd schemas today, and they support attributes that are a sequence of string-tokens with space between (ie. value="Ah Ac Qh") (it's called NMTOKENS)

* check = call with amount = 0

I kindda like having a raise and bet be two different elements but I have changed it back and forth in earlier drafts.

I will take another shot at a draft, incorporating the input so far.

Shoe Lace · #**132** 08-02-2007, 02:02 PM

[ QUOTE ]
That way, you don't have 10 different programmers come up with 10 different ways to append this data to the PokerHand

[/ QUOTE ]

I think hand sharing (via online converter) is going to end up looking 10 different ways no matter what kind of standards we introduce.

I really like the idea of having certain stats automatically placed into the !results of the converter! though. That would be really sick.

Imagine the converter output looked something like:

SB: $25.00 (25/18/0.5)
BB: $25.00 (25/18/0.5)
Hero: $25.00 (25/18/0.5)
CO: $25.00 (25/18/0.5)
BTN: $25.00 (25/18/0.5)

I think this should be left up to the hand analyzer. For online based converters they could have form based fields allowing the user to type out the stats if they really want to, or optionally include stats vs villain in the reads section.

Reads section would be a text box (in both a PT/HM type app or web based).

TSchauenberg · #**133** 08-02-2007, 02:13 PM

[ QUOTE ]

Based on this, there should be a priciple: What is in the site's HH goes into the XML file; what is not in the site's HH doesn't go into the XML file.

[/ QUOTE ]

I think this is a very good principle to go by. The one thing that is worth clarifying is that this statement implies that the XML file has to support the superset of all sites' HH file formats or we have to decide how verbose we can support (i.e. the most common 95% of sites' hands) and cut off the remaining stuff.

I think meta information sections could/should be added in a way that implies they are optional since they are arguably very useful, but not necessary. For example, I really do recommend having an optional summary section as well which contains players' nets, final stage seen, private cards that were visible, and the board so that people can write apps based on just the summary information alone (i.e. poker bankroll graphers, session win/loss trackers, automated equity output, high stakes db player summary web pages), but agree that in the basic standard it isn't necessary to require.

Also, I have not seen any drafts of tourney summary information either. Is this intended as a separate XML format and just linked via a tournament id in both?

Terence.

chipwiz · #**134** 08-02-2007, 02:14 PM

Hi I was just looking for a good xml format for hand histories and came across this thread. I like very much the one MuppetBingo has come up with so far.

Shoe Lace · #**135** 08-02-2007, 02:21 PM

[ QUOTE ]
For example, I really do recommend having an optional summary section as well which contains players' nets, final stage seen, private cards that were visible, and the board so that people can write apps based on just the summary information alone (i.e. poker bankroll graphers, session win/loss trackers, automated equity output, high stakes db player summary web pages), but agree that in the basic standard it isn't necessary to require.

[/ QUOTE ]

Why though? The logic of the application can figure this out.

Ex.

If I wanted to know how much SB lost in a hand all I have to do is take SB's stack size and subtract x from it.

x being whatever he put into the pot on various streets.

Showdown info (their full made hand + result) would be included I think for sure. I can't imagine not being able to store mucked hands.

MuppetBingo · #**136** 08-02-2007, 02:31 PM

[ QUOTE ]
[ QUOTE ]

Based on this, there should be a priciple: What is in the site's HH goes into the XML file; what is not in the site's HH doesn't go into the XML file.

[/ QUOTE ]

I think this is a very good principle to go by. The one thing that is worth clarifying is that this statement implies that the XML file has to support the superset of all sites' HH file formats or we have to decide how verbose we can support (i.e. the most common 95% of sites' hands) and cut off the remaining stuff.

[/ QUOTE ]

I disagree with this, we should include the common elements in all hand histories, which allows us to reconstruct the hand itself.

Fluff like the hand history quoted earlier in the thread from ipoker, does not belong in a common format:

[ QUOTE ]

<ipoints>505.25</ipoints>

[/ QUOTE ]

MuppetBingo · #**137** 08-02-2007, 02:35 PM

[ QUOTE ]

Also, I have not seen any drafts of tourney summary information either. Is this intended as a separate XML format and just linked via a tournament id in both?

[/ QUOTE ]

I was thinking about this as well, I think a structure like this would be best:

<tournament>
<tournamentcontext>
.. buyin, vig, etc..
</tournamentcontext>
<pokerhands>
.. a bunch of pokerhands
</pokerhands>
<tournamentresult>
.. stuff like how much $$ we won and what place we came
</tournamentresult>
</tournament>

Each pokerhand holds the result in terms of chips, while the tournamentresult contains information about real money.

This means the <context> in the earlier drafts will be changed somewhat.

Shoe Lace · #**138** 08-02-2007, 02:37 PM

Here's my last submission. I'm pretty sure work it'll work any game with any cash variant (no limit, limit, pot limit, hi/lo, etc). I never played a tournament in my life so I don't have any HHs. I think with minor tweaks it'll be no problem.

Code:<hr /><pre>
<hand date="00/00/0000 00:00:00pm" site="PokerStars" table="Blah" number="#0000000000" currency="$" seats="6" game="Holdem" type="No Limit" SB="5" BB="10">
<players dealer="4">
<seat id="1" name="Jack" stack="1000" ante="0">
<seat id="2" name="Jill" stack="1000" ante="0">
<seat id="3" name="Jim" stack="1000" ante="0">
<seat id="4" name="Jane" stack="1000" ante="0">
<seat id="5" name="Joe" stack="1000" ante="0">
<seat id="6" name="Julie" stack="1000" ante="0">
</players>
<action>
<street order="1">
<dealer sendsId="3" cards="Kd Qd">
<player position="1" action="Fold" value="0">
<player position="2" action="Fold" value="0">
<player position="3" action="Raise" value="35">
<player position="4" action="Call" value="35">
<player position="5" action="Fold" value="5">
<player position="6" action="Fold" value="10">
</street>
<street order="2">
<dealer sendsId="0" cards="3d Kh Td">
<player position="3" action="Bet" value="60">
<player position="4" action="Call" value="60">
</street>
<street order="3">
<dealer sendsId="0" cards="Jc">
<player position="3" action="Bet" value="205">
<player position="4" action="Call" value="205">
</street>
<street order="4">
<dealer sendsId="0" cards="2d">
<player position="3" action="Bet" value="525">
<player position="4" action="Call" value="525">
</street>
[note: this would be the output of a normal showdown]
<showdown>
<player position="3" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<player position="4" hand="[3c 3h] 3d Kh Jc (Three of a kind, Threes)" result="muck">
<award position="3" pot="main" rake="5">
</showdown>
[/normal showshown]
[note: this would be the output for a split pot showdown]
<showdown>
<player position="2" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<player position="3" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<player position="4" hand="[3c 3h] 3d Kh Jc (Three of a kind, Threes)" result="muck">
<award position="2" pot="main" rake="2.5">
<award position="3" pot="main" rake="2.5">
</showdown>
[/split showdown]
[note: this would be the output of a side pot showdown]
<showdown>
<player position="3" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<player position="4" hand="[3c 3h] 3d Kh Jc (Three of a kind, Threes)" result="muck">
<award position="3" pot="main" rake="2.5">
<award position="4" pot="side" rake="2.5">
</showdown>
[/side showshown]
</action>
</hand>
</pre><hr />

Some things to note.

1) There is no definition of Cash/Tournament because it's not needed. If the currency is "t" then it's a tournament. If there's no currency then it's play money. If it's anything else, it's some form of money. My only concern is how tournament payments are handled in PT (how does it know which currency the payment was, and how is it entered?). I never played a tournament in my life, nor have a HH to look at. If it ends up being a big deal, then put in a "mode" attribute on top, its value would either be "Ring" or "Tournament".

2) Antes are in for each player for reasons stated by someone previously. Some tournament formats require you to post antes even if you are sitting out while some cash games do not.

3) <dealer sendsId="3" cards="Kd Qd"> is used on every street. It does what it says. It sends those cards to the player who belongs to seat id #3. In the real world this identifies hero when it happens on street order #1. An id can never be 0 so we can have a general rule that whenever an id is 0 it belongs to the community. If it is not 0, then the card is either a hidden or visible hole card. The hand analyzer will determine if it should be visible or not based on the rules of the game (ie. has nothing to do with the xml file).

4) 'position' values are literal position in the hand, not the seat order. The actual seats are defined by "id" up top. The hand analyzer will put in the correct positions when it parses the original hand history.

5) Each street has an order for obvious reasons. We want to be able to read the hand if it's not in order. Having the name of the street (as an alias) is not needed.

6) Show downs should be self explanatory. The "main" and "side" values are coming from the actual HH history but the person parsing the file can make it always say "main" instead of "mainpot" in the XML file if a site happens to word it differently. This means getting a Hi/Lo pot would be no problem.

7) The rake is included for each winner because the rake will vary depending on which pot they won.

8) An award element is introduced because it is awarding someone the pot and this can happen more than once.

For all the people who nit-pick over how the cards should be displayed this format allows you to easily pick a method. The dealer element is an event that could occur more than once per street.

OrcaDK · #**139** 08-02-2007, 02:42 PM

[ QUOTE ]
Another question to throw out there, should we include optional metadata definitions for things like reads and player stats?

When these xml files start being shared across applications it would be nice to have a standardized way of storing this type of information. Obviously I'm not talking about identifying every stat but more of a framework within the metadata to describe whatever stats / reads you want to include in the hand. That way, you don't have 10 different programmers come up with 10 different ways to append this data to the PokerHand

Or... do we take an approach where we have a MarkedUpPokerHand which includes the PokerHand definition and these other additional items?

rvg

[/ QUOTE ]

I believe including the metadata is a big error. The metadata is not logically related to the hand itself, it's related to the players. And the reason for this format is not to share hands among players, it's for applications to more easily support several sites as there will hopefully be a community effort to keep the converts up-to-date. Reads should be for the implementing applications to add.

OrcaDK · #**140** 08-02-2007, 02:46 PM

[ QUOTE ]
Based on this, there should be a priciple: What is in the site's HH goes into the XML file; what is not in the site's HH doesn't go into the XML file.

Random comments:

1) The sites' put a textual description of the hand in the HH: "Flush A high." If that is in the HH, it should be in the XML file because it saves the site's evaluation of the hand.

2) Muppet's idea of rounds with cards and actions associated with each round is great. The rounds should be numbered and named. The number is the order in which the rounds are played. The name is what the site calls that round in its HH. This avoids confusion between "Turn" and "Fourth Street".

3) If the model above is correct then representing cards by "Ac" is adequate.

[/ QUOTE ]

I disagree with all three points.

1)
The sites textual descriptions should in no way be included. This also goes for (2). The whole point of making a standardised format is to make a generic format that has no relation to the pokersite at all, besides an attribute/element that points out the originating pokersite.

2)
The name should not be there! If we start using the poker sites terms then we are no further than we are right now! Then the implementing applications will still have to distinguish between the various sites.

3)
Splitting up the suit and card value makes for lot easier querying as we have already discussed earlier - see my RDB / XPath example.