Poker Hand XML

[rvg72]

I have converters built for 5 sites - you guys figure out what you want it to look like and I'll change the output to match it. Ideally open-source convertors will be created (which I'd probably take part in) but for now this would give the format instant life. I could also provide an app independant of HM that you simply copy and paste a hand history and it outputs the xml format.

rvg

[MuppetBingo]

[ QUOTE ]
Great discussion so far. Some point soon the group should decide on a couple of people to collaborate and take a shot at the first draft.

rvg

[/ QUOTE ]

I nominate OrcaDK.

[mikechops]

[ QUOTE ]
[ QUOTE ]
Great discussion so far. Some point soon the group should decide on a couple of people to collaborate and take a shot at the first draft.

rvg

[/ QUOTE ]

I nominate OrcaDK.

[/ QUOTE ]

...and Shoe Lace [img]/images/graemlins/smile.gif[/img]

[ThirdEye]

i'm in the middle of coding a poker tool myself (working on it since over a year) and asked myself similar questions about the future of HH parsing.

i think inventing our own xml standard won't help that much, because this is something the pokersites should be doing...

personally, i would be MUCH MORE interested in discussing a good poker database format.

given that database format, a standard parser (dll) would be the way to go imho.

this would tremendously cut down time both for the coders and the users.

[Triggerle]

I have no direct programming interest in this but it really strikes me as odd to take "a shortcut" with the hole cards by concatinating them instead of doing it the right way(TM) from the start.

I guess I've seen too many databases where it was a pain in the butt to program around the limitations of short-sighted design.

[MuppetBingo]

@ThirdEye

Today every tool that has to handle hand histories needs to write it's own converters, and since there are a big number of sites and their hand history structure changes with time, it's not a trivial effort to keep all the converters up to date. (Take a look at the release notes for Pokertracker for an example)

The consequence is that many tools don't accept more than a handful of the most popular sites' hand-histories. hand converters is a good example of this problem: I can't find a hand converter that can accept Pacific Poker hand histories, and export to 2+2 format. If we had a common xml-format for tools to accept as input, then we (as a community) would only have to keep one set of hand history converters up-to-date, and support for minor sites would be more prevalent.

The sites themselves will probably never use an xml format, because they really don't have an incentive to. Even if the xml format were to become wildly popular, I doubt players would care enough about what format the sites exported hand histories in enough to switch vendor (site).

[ThirdEye]

[ QUOTE ]
@ThirdEye
The consequence is that many tools don't accept more than a handful of the most popular sites' hand-histories. hand converters is a good example of this problem: I can't find a hand converter that can accept Pacific Poker hand histories, and export to 2+2 format. If we had a common xml-format for tools to accept as input, then we (as a community) would only have to keep one set of hand history converters up-to-date, and support for minor sites would be more prevalent.

[/ QUOTE ]

yes, that is right, but why not go a step further ??

with a common parser (and database), you would have the same advantages and more...

even with a common xml format, the process would be:

HH > XML
XML > proprietary database
access proprietary DB to do something useful

now what i want is:

HH > standard DB
access standard DB

all tools would work with the same parser and the same DB schema...

using ORM (object relation mapping) tools, that schema could even run on different DB systems. (i do that with my own tool aready, supporting more then a dozen DB systems)

database integrity and quality would be much better if we would all work on the same schema.

believe me, you would get tools you can't even imagine in your wildest dreams if future tools would use a common DB format and an open source parser...

that open source parser could add mechanics to easily add HH formats without the need of a coder.

it's just an idea. supporting a new HHXML format would be no problem for most developers, but it's not the optimal solution imho...

most (if not all) poker DB schemas i have seen so far are pretty awkward and i think a basic discussion about this topic could be very interesting.

but i do not want to hijack this thread, just something that crossed my mind, because it took a lot of my time re-designing my own schema over and over...

[Phil153]

You'll never create a useful standard database as there are too many size/speed/usage tradeoffs for the "not in your wildest dreams" kind of tools.

You really have to bind the database to a specific solution.

[Shoe Lace]

If this is going to be an open-source community project (which I believe is the only option considering what we want to do) then we're going to have to discuss another fun topic.

1. Is the app going to be a standalone executable in addition to being a plug-in for any popular hand analyzers that happen to pop up (PT/HM/etc)?

2. What language will it be written in?

3. How are we going to manage/distribute the project to make sure everyone is working with an up to date version.

I'm thinking ->

1. I'm not sure if having a stand alone executable is too useful. The web based converters (so we can post hands online cleanly) will be treating our format just like they treat poker stars or any other site. It wouldn't take them very long to support it.

If the app is a plug-in of an existing app like HM then HM will invoke the actual conversions of hand histories. There's really no reason to convert a hand to this format by itself.

2. This is going to be tough... so many choices. I like C#. The .NET framework is quite flexible and performance is reasonable.

3. Source forge I guess?

[TSchauenberg]

Hi all,

I am late to the party on this thread but think it is a really great idea. I am sure Poker Academy Prospector will support this format as well so like HM and LegoPoker and everyone else we will help get this adopted.

I haven't had a chance to read every post here but here are some problems I have seen with existing hand histories that online sites use that the format we define should avoid:
* explicitly list the size of the antes, and blinds (not always recoverable from actions alone)
* explicitly list the location of the button
* saying raise some amount often requires a lot of interpretation to figure out how much the player has to put in the pot for that action (i.e. depends on the bets and raises to them since they last acted) so maybe our format could help there like pokergrader suggested
* saying when a player is treated all-in with an action is a good modifier and lets various capped betting games be handled as well as disconnect protects and makes regular action bookeeping go more smoothly
* need to explicitly list where uncalled chips are returned
* 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
* lots of sites handle tournament players who are sitting out in a special way where they have their cards mucked/folded even when they are all-in.
* tournament information should be considered
* user/program added hand comments should be considered
* need to be able to handle/flag potential missing/bad data (for example, missing tournament IDs, partial hands, etc.)

I am sure I have missed lots so far, but I will read the threads and drafts again tomorrow and comment again.

Terence.