Poker Hand XML

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
I don't see the harm in having an optional attribute for player reads. I don't think anybody is proposing making this mandatory. All rvg is saying is that he will want to add player reads/notes for some hnads and he would like to get agreement on the best way to do this. My understanding of xml is limited but if a parser is expecting :-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0"/>

it should not break if it gets:-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0" read = "85/40/0.1 DONKEY!"/>

The advantage of specifying at this point how reads should be stored, is that anyone writing an application using rvg's reads will also be able to take advantage of anybody else's app that exported reads in the same standard.

Like I said I don't know much about xml and if we would have to include a blank field for players with no read data, then I withdraw everything I just said.


[/ QUOTE ]
If we are to do this, then it must not be via an attribute, that leaves us far too few options as we can't even allow CDATA in there. I propose that we add a <metadata> element to the hand of type CDATA. This metadata section could then include any number of XML structures, delimited text or whatever, containing the reads, meta instructions and so forth. That'll be an optional element and any parsers can simply ignore that element unless they have a reason not to.


[/ QUOTE ]

Sorry I didn't understand this. What is the problem with including an attribute for the reads?

[/ QUOTE ]
My problem is that reads really do not belong together with the hand as an objective way of transferring hands. If we add a <metadata> section we could put anything in here that we wish, reads, internal application data, wish letters for santa. It'd be totally up to the application creating the XML file what it wanted to put in here. It really is ugly to include this with the hand as it does not belong there.

[Shoe Lace]

[ QUOTE ]
How would a programmer implement a routine that calculates the pot size at a given point in the hand?

[/ QUOTE ]

It can be done a number of ways. For simplicity (in this post), we'll just use an array, but I think a "major analyzer" would do it differently -- either way the result is the same.

Say we have an array called potSize.

Each element of the array will store the total pot size for a specific street order. The index of the array will let us know which street it belongs to.

The array values could be set to include the grand total of the pot size instead of -just the action of that street- but really this depends on what the application is used for.

Some apps might require how much was invested per street without wanting to know the total pot size, while others only care about the grand total.

This process can be done automatically inside of a loop. This allows us to figure out the pot size on each street regardless of the game type because it would work with 2 streets or 200 streets because we'll have a street id in our XML file and our loop will go from 1 to x (where x is the highest street id).

[mikechops]

Yeah that's roughly how I would do it too, but I think you may be missing the point...

However you do it, it will be a lot easier if the "amount" field of each action is always either the new chips put into the pot, or total chips put in so far. Having the amount mean different things for different actions is messier.

[Shoe Lace]

[ QUOTE ]
Where do you get the 15% from? If you look back just a short way someone proposed that we include this in the players section, the section where we already note the players starting stacks, name and so forth. We could simply add the net win/loss and hand win/loss status here, that would take up very very little space.

[/ QUOTE ]

This idea is fine, but it's still quite a bit of extra info.

Say our tag is:
[SPACECHAR]net="-18345.32"

This is 16 characters (a space counts as 1 char). Multiply it by 9 and we get 144.

I still believe we can get a typical hand to about 1800-1900 bytes total with a solid layout. Perhaps a bit more once we figure out how to include tournaments perfectly.

15% was a bit much but we're still looking at 3-7% depending on how big the net is and how many players are at the table.

I still don't see the point. This hand summary application will need to -open- the xml file and then parse out whatever he wants. I'm guessing all the game header data (site, date, currency, blinds, etc) and the player name + net.

The app might even want to include position because it would be useful to know how much you are netting from various positions.

At this point it's not a gigantic deal to just figure out the net by reading the hand. Yes it's more work for this specific application, but we're not talking an amount that's going to cause problems. He's doing the majority of the performance related work already.

On the other hand, unnecessary information is always a problem because the negative effects become larger as your xml files grow.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
Where do you get the 15% from? If you look back just a short way someone proposed that we include this in the players section, the section where we already note the players starting stacks, name and so forth. We could simply add the net win/loss and hand win/loss status here, that would take up very very little space.

[/ QUOTE ]

This idea is fine, but it's still quite a bit of extra info.

Say our tag is:
[SPACECHAR]net="-18345.32"

This is 16 characters (a space counts as 1 char). Multiply it by 9 and we get 144.

I still believe we can get a typical hand to about 1800-1900 bytes total with a solid layout. Perhaps a bit more once we figure out how to include tournaments perfectly.

15% was a bit much but we're still looking at 3-7% depending on how big the net is and how many players are at the table.

I still don't see the point. This hand summary application will need to -open- the xml file and then parse out whatever he wants. I'm guessing all the game header data (site, date, currency, blinds, etc) and the player name + net.

The app might even want to include position because it would be useful to know how much you are netting from various positions.

At this point it's not a gigantic deal to just figure out the net by reading the hand. Yes it's more work for this specific application, but we're not talking an amount that's going to cause problems.

On the other hand, unnecessary information is always a problem because the negative effects become larger as your xml files grow.

[/ QUOTE ]

As has been said several times before. Size is not really a matter. This format is primarily for transferring smaller chunks of hands. Furthermore text compression is extremely capable. Lastly, if you want to reduce size so much, you really should go for a binary format instead of XML.

I have no further arguments. My position stands, but I cannot say anymore than I have already done.

[Shoe Lace]

[ QUOTE ]
As has been said several times before. Size is not really a matter.

[/ QUOTE ]

I'm not talking about HD space. Why don't you write an application that opens and parses specific information from a file.

Test 1 -> File size: 20kb
Test 2 -> File size: 380kb

These are extreme examples, but to say that size doesn't matter is ridiculous.

I think in the real world it won't matter if the net is put in or not but lazy programmers who just have the thought process of "whatever, it's good enough" annoy me to know end.

Btw, we can go back and forth endlessly. I think about 10 pages ago we determined that a hand history should not have calculations, it should be a means of storing hand data. What's done with the data is up to the application using it.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
As has been said several times before. Size is not really a matter.

[/ QUOTE ]

I'm not talking about HD space. Why don't you write an application that opens and parses specific information from a file.

Test 1 -> File size: 20kb
Test 2 -> File size: 380kb

These are extreme examples, but to say that size doesn't matter is ridiculous.

I think in the real world it won't matter if the net is put in or not but lazy programmers who just have the thought process of "whatever, it's good enough" annoy me to know end.

Btw, we can go back and forth endlessly. I think about 10 pages ago we determined that a hand history should not have calculations, it should be a means of storing hand data. What's done with the data is up to the application using it.

[/ QUOTE ]
I won't even comment on that example as you know it is ridicilous. Yes, I know it was an extreme example, but please.

I just came up with another argument. What is the purpose of this standard? It is to further enhance the amount and quality of 3rd party applications right? By not providing the winning hand and net amount, we add a lot of extra work effort to a lot of 3rd party applications that might not care about the actual hand actions themselves. By adding these bits of info we enable a lot of possible applications to be written in zero time.

You call them calculations, while technically correct, I do think they deserve another notation. Writing the ROI of each player on each street, that is a calculation. Writing each players final hand strength, that is a calculation - and is something the writing application will rarely know of if the site does not provide this information. The final pot size and the winning hand is always written in the original hand histories, it's simply a part of the hand, who won and who didn't.

Let's take a quite rare situation, the pokersite named the wrong hand the winner. Wouldn't you want that to be preserved in the hand history? Same thing goes for pot sizes / awards.

[wallenborn]

[ QUOTE ]
My problem is that reads really do not belong together with the hand as an objective way of transferring hands. If we add a <metadata> section we could put anything in here that we wish, reads, internal application data, wish letters for santa. It'd be totally up to the application creating the XML file what it wanted to put in here. It really is ugly to include this with the hand as it does not belong there.

[/ QUOTE ]

I see the problem the same way, but will a metadata element really solve it? Maybe we'd want to include comments after streets or even after actions? In that case, having them in a separate metadata container could make retrieval rather difficult. I can't think of a good way to write this in XSL for example without adding marker ids or reference labels.

The popopop replayer uses an XML storage format that mostly sucks, but one thing i like about it is that <comment> is an optional element to <actions>. So most actions look like

<Action seatNumber="3" actionID="4" />

(the actionIDs obviously suck), but some are like this:

<Action seatNumber="2" actionID="16">
<comment>nh, sir</comment>
</Action>

Since the comments are elements and not attributes, they can be CDATA.

Doesn't answer your initial objection, though. Player reads are not part of a hand. If someone develops a container format for sequences of hands, it would be cumbersome to have the reads in one particular hand.

On the other hand, someone who creates such a container format could define a suitable <reads> element, so maybe the question is academic.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
My problem is that reads really do not belong together with the hand as an objective way of transferring hands. If we add a <metadata> section we could put anything in here that we wish, reads, internal application data, wish letters for santa. It'd be totally up to the application creating the XML file what it wanted to put in here. It really is ugly to include this with the hand as it does not belong there.

[/ QUOTE ]

I see the problem the same way, but will a metadata element really solve it? Maybe we'd want to include comments after streets or even after actions? In that case, having them in a separate metadata container could make retrieval rather difficult. I can't think of a good way to write this in XSL for example without adding marker ids or reference labels.

The popopop replayer uses an XML storage format that mostly sucks, but one thing i like about it is that <comment> is an optional element to <actions>. So most actions look like

<Action seatNumber="3" actionID="4" />

(the actionIDs obviously suck), but some are like this:

<Action seatNumber="2" actionID="16">
<comment>nh, sir</comment>
</Action>

Since the comments are elements and not attributes, they can be CDATA.

Doesn't answer your initial objection, though. Player reads are not part of a hand. If someone develops a container format for sequences of hands, it would be cumbersome to have the reads in one particular hand.

On the other hand, someone who creates such a container format could define a suitable <reads> element, so maybe the question is academic.

[/ QUOTE ]

Well, while I do not believe reads should be part of the hand, comments actually ought to be, or? I mean, they're part of the hand as it played out on the pokersite. All pokersites include player comments in the histories as well. I don't really know about those...

As for reads, I do not think we should include them in the <comment> tag. I still think we should either totally omit them or place them in some section that is totally seperate from the actual hand and which can easily be ignored.

[Phil153]

I think in-hand comments are important and should be part of the hand. End users are going to want the chat recorded, and it allows us to throw away the original hand history without losing information. It makes no sense to me to put in extra data such as the won/lost of every player (which can easily be calculated or queried), but throw away data that people actually want. Multiple blogs and hand postings show that people are interested in and want to store this information.

I'm not aware if there are issues with doing this on the smaller sites (such as issues identifying who said what, and separating from announcements), but I doubt it will be much of a problem for those writing parsers.

A simple <chat> tag makes the most sense for this I think. It'd be simply:
<chat name="Phil153">nice hand idiot</chat>

I'm not sure if we should have a field for "name" or not, since some sites don't always identify who said what (i.e. Party usually does but sometimes misses). One of the problem of including non-player identified chat is that you can get announcements and spam in a hand. But on the other hand, people sometimes want to save railbird chat, so perhaps a direct copy of the entire line, such as:
<chat>Phil153: blah blah</chat>
might be best, and leave the parsing up to the application. Regardless of what we do, I think we should at least include player identifiable chat.

Thoughts?