Poker Hand XML - Page 6

pokergrader · #51 07-31-2007, 08:22 PM

[ QUOTE ]
I still think I'd prefer cards coactenated. It's trivial to parse them, it takes up much less space and makes the hand a little easier on the eye. But whatever...

[/ QUOTE ]

I agree, and I think card representations should be standard as [23456789TJQKA][shdc], which is what the majority of sites use.

Tickner · #52 07-31-2007, 08:42 PM

[ QUOTE ]
I still think I'd prefer cards coactenated. It's trivial to parse them, it takes up much less space and makes the hand a little easier on the eye. But whatever...

[/ QUOTE ]

But they are each a seperate piece of data

jamzfive · #53 07-31-2007, 10:05 PM

[ QUOTE ]

One thing that you have to realise concerning xml is that you should never ever make any xml standard that is positional depending.

If you have an action section like this:

<hand>
starting stack info, handnumber etc.....
<preflopaction>
<blind>
<player1 kind=sb>$0.10</player1>
<player2 kind=bb>$0.20</player2>
<player3 kind=lb>$0.20</player3>

The sequence of the above <player1>, <player2> and <player3> are not required to be in exactly that order, if they are it is not xml. No order is to be infered by the sequence, it has to be inferred by the attributes, in this case the kind attribute where sb is small blind, lb is live blind.

[/ QUOTE ]

Maybe this used to be true, but it's certainly not still the case, as "sequence" is one of the compositors available in the XML Schema specification.

jb

jamzfive · #54 07-31-2007, 10:11 PM

[ QUOTE ]
Yes, I am excited about this as well rvg, and LegoPoker Hand History Converter will be on the frontier of this technology and will definitely be supporting it.

Realistically we can have a working version of this within 5-7 days if we all cooperate.

The first question we need to answer is:

Should XML be used or another format?

Myself and a few others have shown strong interest in XML but there have been some valid points about NOT using XML.

From this post on, until this question is answered by the community, I am going to assume we like XML and am going to start askign some generic questions.

1. What date format should be used?

...

This last one is my favorite. But just because its my favorite doesn't mean it is best. What are YOUR thoughts? We need everyones opinion here to formulate the best format.

[/ QUOTE ]

I would vote for none of the above. The XML Schema 1.1 Part 2 specification describes a "standard" dateTime format for XML. Schema-aware parsers will have built-in support to be able to recognize and parse it.

jb

CudjoeBill · #55 07-31-2007, 10:20 PM

Just wanted to say, Excellent thread!

A couple of observations (based on my quick browsing of this thread).

1: I agree XML is the best format. One of the principles of XML is that it allows for future flexibility. In other words, since XML relies on elements & attributes to identify data, you can in theory add data elements and/or attibutes at a later date without breaking existing parsers. How many times have we all written a parser to look for this data, at this position, only to have our parser break later down the road when a vendor/customer decides to add a new piece of data in the middle of the record. No matter how much we anticipate how we will consume the data, there is always the possibility that at a later date we will want to include some new data to consume. Or that we will change our minds on how we want to consume the existing data.

2: Human readability is not a neccesity, but it sure makes quick and dirty debugging easier. Since we should be using a well-defined, strongly-typed schema to validate our data, you may think that human readability is not needed. But it is awfully nice to be able to open an XML file in any text editor and quickly scan for obvious problems. I mean, our parser may say, "Error on line 527 - Action invalid", but if we can open the file in Notepad++ (or the text editor of your choice), go to line 527 and see that the action is "Rais" when it should be "Raised", human readability makes it that much easier to resolve the error quickly.

3: Date/Time format is just that, a format of data. Use an element to store the data and an attribute to define the format used. Similar to a Regional Settings in Windows. The data is in the element, and the format/regional setting attribute should define how to interpret that data.

4: The schema should be used to define valid elements and attributes (for instance, valid actions might include Check, Call, Bet, and Raise). If we use a flexible schema, then it will be easier to add additional actions at a later date (like Check-Raise or Re-Raise or Re-Re-Raise). For instance, let's say we design the original schema to be used for NL Hold'em. What if we want to expand the schema later to accomodate for H.O.R.S.E. or some other new poker game that before now did not exist? Since the schema defines the elements and attributes, we have the ability to change the schema to accomodate this. If we all read the schema before we transform the file, we allow ourselves a tremendous amount of flexibility.

5: Each action should be recorded. Right now, we can deduce what happened by examining the sequence of events. If player F bets $0.50 and player B bets $1.00 and we go to the flop, then either player F was in a blind or perhaps player F paid a missed blind penalty of $0.50 before the hand was dealt (or other circumstances may have unfolded, I think you get my point). So we should strive to record as many actions as possible. Obviously, depending on the original hand history we may still have to deduce what happened, but we should strive to record as many actions as possible.

6: Currency is also just a format. Use an element to store the "units" and an attribute to define the format of the element. What happens if the UK decides to switch to the Euro next year? Or what happens if a Russian player decides to compare his winnings with a US player, dollar for dollar?

7: Sequence is important. The order in which actions occur is not neccesarily the order in which they are recorded in the hand history file. This is not a trivial matter. I don't know how we enforce this requirement with the poker sites, but maybe we at least include a sequence attribute when we parse the hand history files. If nothing else, maybe this gives us some ammunition to request changes to the way poker sites record events that occur at the table.

8: Original Hand Histories should be kept. Why? This project is a moving target. What is important today, might not be important tomorrow. By the same token, what we deem to be irrelevant today, might be critical tomorrow. If we keep a copy of the original hand histories, we are in essence reserving the right to change our minds later, with a minimal amount of pain and aggrevation.

9: Include the version number of the schema in the root element (or at the least as an attribute of the root element). Let's say we all decide on a schema that is great, v1.5. Later, we all decide to change the schema to v1.6. How will our parsers know which schema to use when validating the file? By including the intended version number somewhere in the XML file, we can make sure that the correct schema is being used to validate the file.

That's all for now. I have more ideas and comments, but I have more posts to respond to before I hit the hay.

Like I said, this thread is excellent. Let's keep the discussions going!

CB

Shoe Lace · #56 08-01-2007, 04:08 AM

How about something like this? I tried to keep things minimal without screwing up the readability too bad.

I tried to do the following:

1) Reduce redundancy.
2) Keep it clean and easy to follow.
3) Didn't include things that could be figured out through code (like the pot size on each street or the specific player name on each street, because we already defined that once).

This is what a specific hand would look like:

<font class="small">Code:</font><hr /><pre>
<hand date="00/00/0000 00:00:00pm" site="Poker Stars" number="#0000000000" currency="$" type="Cash" seats="6" game="Texas Holdem" blinds="5/10">
<players>
<seat position="1" name="Jack" stack="1000">
<seat position="2" name="Jill" stack="1000">
<seat position="3" name="Jim" stack="1000" holecards="Kd Qd">
<seat position="4" name="Jane" stack="1000">
<seat position="5" name="Joe" stack="1000">
<seat position="6" name="Julie" stack="1000">
</players>
<action>
<street order="1">
<position="1" action="Fold" value="0">
<position="2" action="Fold" value="0">
<position="3" action="Raise" value="35">
<position="4" action="Call" value="35">
<position="5" action="Fold" value="5">
<position="6" action="Fold" value="10">
</street>
<street order="2" board="3d Kh Td">
<position="3" action="Bet" value="60">
<position="4" action="Call" value="60">
</street>
<street order="3" board="3d Kh Td Jc">
<position="3" action="Bet" value="205">
<position="4" action="Call" value="205">
</street>
<street order="4" board="3d Kh Td Jc 2d">
<position="3" action="Bet" value="525">
<position="4" action="Call" value="525">
</street>
<showdown>
<position="3" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<position="4" hand="[3c 3h] 3d Kh Jc (Three of a kind)" result="muck">
<award position="3" value="1660" rake="5">
</showdown>
</action>
</hand>
</pre><hr />

As for things like play money or jackpots, this would be included in the "type" as optional data if it's included in the actual hand history.

Example, a jackpot cash game could be set as: type="Cash(Jackpot)"

It's also rigged to easily support other game types or table sizes.

Edit:
If we didn't care at all about file size and wanted to increase human readability we could introduce a new attribute to the "street" elements. It could be labeled as "alias".

This alias would hold terms associated with the game.

A line might look like this for holdem:
<street alias="river" order="4" board="3d Kh Td Jc 2d">

Shoe Lace · #57 08-01-2007, 05:03 AM

I forgot a few attributes up top, but I can't edit the post.

- "table" can go in between 'site' and 'number' up top to include the table name.
- Blinds could be separated into 2 attributes ("sb" and "bb" to eliminate parsing).
- "mode" can go after the 'game' attribute. This will handle NL/Limit/PL, etc..

Play money shouldn't be an optional type. The currency should be null instead. A tournament type would ignore the currency attribute or maybe use "chips"/"c".

Then have an "extras" attribute up top to cover weird things like jackpot tables.

So... it would look like this in the end:
<font class="small">Code:</font><hr /><pre>
<hand date="00/00/0000 00:00:00pm" site="Poker Stars" table="Blah" number="#0000000000" currency="$" type="Cash" seats="6" game="Texas Holdem" mode="No Limit" sb="5" bb="10" extras="">
<players>
<seat position="1" name="Jack" stack="1000">
<seat position="2" name="Jill" stack="1000">
<seat position="3" name="Jim" stack="1000" holecards="Kd Qd">
<seat position="4" name="Jane" stack="1000">
<seat position="5" name="Joe" stack="1000">
<seat position="6" name="Julie" stack="1000">
</players>
<action>
<street order="1">
<position="1" action="Fold" value="0">
<position="2" action="Fold" value="0">
<position="3" action="Raise" value="35">
<position="4" action="Call" value="35">
<position="5" action="Fold" value="5">
<position="6" action="Fold" value="10">
</street>
<street order="2" board="3d Kh Td">
<position="3" action="Bet" value="60">
<position="4" action="Call" value="60">
</street>
<street order="3" board="3d Kh Td Jc">
<position="3" action="Bet" value="205">
<position="4" action="Call" value="205">
</street>
<street order="4" board="3d Kh Td Jc 2d">
<position="3" action="Bet" value="525">
<position="4" action="Call" value="525">
</street>
<showdown>
<position="3" hand="[Kd Qd] Td 3d 2d (King-high Flush)" result="win">
<position="4" hand="[3c 3h] 3d Kh Jc (Three of a kind)" result="muck">
<award position="3" value="1660" rake="5">
</showdown>
</action>
</hand>
</pre><hr />

mikechops · #58 08-01-2007, 06:44 AM

[ QUOTE ]
[ QUOTE ]
I still think I'd prefer cards coactenated. It's trivial to parse them, it takes up much less space and makes the hand a little easier on the eye. But whatever...

[/ QUOTE ]

But they are each a seperate piece of data

[/ QUOTE ]

I've given two advantages of combining them. And the advantage of separating them is?

UnknownName3 · #59 08-01-2007, 08:47 AM

Random points:
1. Shouldn't we keep the cards as separate pieces of data (separated) for the "eventual" expansion of other games (specifically, stud or draw)?

2. I agree with associating cards being dealt to particular seats rather than player IDs.

3. We should consider creating a "side-pot index" attribute to keep track of side pots. Default is 0; When 2 or more players are in a side pot, <side_pot_index = 1>.
ex) All players are "all-in" except seat 4
seat 1 - 500 chips
seat 2 - 1000 chips
seat 3 - 1500 chips
seat 4 - 2000 chips

<seat id="1" [...] side_pot_index="0">
<seat id="2" [...] side_pot_index="1">
<seat id="3" [...] side_pot_index="2">
<seat id="4" [...] side_pot_index="3">

4. For split-pot games, should we create a separate lo and hi hand attributes?
ex from able)
<player _name="player3" showed_hand="true" ALLIN="1" stack="381" cards="3d4h5h7h6c8h5s" hi_hand="HI: a straight, Four to Eight" lo_hand: LO: 7,6,5,4,3" seat="3"/>

Tickner · #60 08-01-2007, 09:10 AM

Thanks Show Lace, that looks decent, certainly smaller than the one I proposed, but I still think its missing some data and it isn't formatted right (element names cant be assigned values, i.e. <position="1" ...>

mikechops, you make a good point in that yes it helps humans read it better and yes it takes up less space. Its worth considering that maybe this might be best. I will give this more time to be talked about by everyone (Please tell us your opinion on this). It is my opinion that each card is a seperate piece of data and should be parsed inidividually instead of making the reader do the extra work (which the read will have to do every time). So essentially this is just a space/human readability issue, right?

UnkonwnName3, we definitely need a way to deal with sidepots but I dont think your solution is good. The reader of the PokerHandXML will have to do some logical analysis on the data to determine who is in which pot etc etc, the XML can't hold ALL of the information, but we do provide enough information for it to figure it our correctly each time. In my example I used a "pots" element...

<font class="small">Code:</font><hr /><pre>
#
<pokerhand>
#
<gameinformation type="tournament" online="true">
#
<room>PartyPoker</room>
#
<game>TexasHoldem</game>
#
<format>NoLimit</format>
#
<currency>$</currency>
#
<datetime>2007-07-31T11:38:00-05:00</datetime>
#
<id>11082740019</id>
#
<blinds>
#
<ante>0.00</ante>
#
<small>10.00</small>
#
<big>20.00</big>
#
<post>0.00</post>
#
<straddle>0.00</straddle>
#
</blinds>
#
<tournament>
#
<buyin>1.00</buyin>
#
<vig>0.20</vig>
#
<id>56210298</id>
#
<currency>t</currency>
#
</tournament>
#
<table>
#
<name></name>
#
<id>562102981</id>
#
</table>
#
<cashgame>
#
<maxbuyin></maxbuyin>
#
<cap></cap>
#
</cashgame>
#
</gameinformation>
#
<seats>
#
<seat number="1" player="player1" stack="1500" />
#
<seat number="2" player="player2" stack="1500" />
#
<seat number="3" player="player3" stack="1500" />
#
<seat number="4" player="player4" stack="1500" />
#
<seat number="5" player="player5" stack="1500" />
#
<seat number="6" player="player6" stack="1500" />
#
<seat number="7" player="player7" stack="1500" />
#
<seat number="8" player="player8" stack="1500" />
#
<seat number="9" player="player9" stack="1500" />
#
<seat number="10" player="player10" stack="1500" />
#
</seats>
#
<forcedbets>
#
<smallblind>player2</smallblind>
#
<bigblind>player3</bigblind>
#
<straddle></straddle>
#
<poster></poster>
#
<ante></ante>
#
<ante></ante>
#
</forcedbets>
#
<betting>
#
<round number="1">
#
<cards>
#
<card player="player1" pocket="true" value="As" />
#
<card player="player1" pocket="true" value="Ac" />
#
</cards>
#
<actions>
#
<action order="1" player="player4" type="raise" wager="40" />
#
<action order="2" player="player5" type="fold" />
#
<action order="3" player="player6" type="fold" />
#
<action order="4" player="player7" type="raise" wager="80" />
#
<action order="5" player="player8" type="fold" />
#
<action order="6" player="player9" type="fold" />
#
<action order="7" player="player1" type="raise" wager="120" />
#
<action order="8" player="player2" type="fold" />
#
<action order="8" player="player3" type="fold" />
#
<action order="8" player="player4" type="fold" />
#
<action order="9" player="player7" type="call" wager="40" />
#
</actions>
#
</round>
#
<round number="2">
#
<cards>
#
<card pocket="false" value="Ah" />
#
<card pocket="false" value="5c" />
#
<card pocket="false" value="Th" />
#
</cards>
#
<actions>
#
<action order="1" player="player4" type="bet" wager="1380" />
#
<action order="2" player="player7" type="fold" />
#
<action order="3" player="player4" type="return" wager="1380" />
#
</actions>
#
</round>
#
</betting>
#
<summary>
#
<totalpot>280.00</totalpot>
#
<pots>
#
<pot number="1">280.00</pot>
#
</pots>
#
<rake>0.00</rake>
#
<seats>
#
<seat number="1" player="player1" net="150.00" winner="1" pot="1" />
#
<seat number="2" player="player2" net="-10.00" />
#
<seat number="3" player="player3" net="-20.00" />
#
<seat number="4" player="player4" net="0.00" />
#
<seat number="5" player="player5" net="0.00" />
#
<seat number="6" player="player6" net="0.00" />
#
<seat number="7" player="player7" net="-120.00" />
#
<seat number="8" player="player8" net="0.00" />
#
<seat number="9" player="player9" net="0.00" />
#
<seat number="10" player="player10" net="0.00" />
#
</seats>
#
</summary>
#
</pokerhand>
</pre><hr />