Poker Hand XML

[Phil153]

[ QUOTE ]
some questions that need to be answered:

[/ QUOTE ]
My thoughts (I'll post more later):

- should it be easily readable by humans?

Desirable but inconsistent with the other goals. If human readable and easy parsing for non-XML coders is the goal then instead of HM's solution perhaps we should just do away with XML altogether.

- does filesize matter? (bloated xml tags?)

I think text compression is pretty good for database storage. In terms of hand sharing, size does obviously matter. I'd imagine tag-bloat for well written xml would be 3-5x. I guess we could mitigate this pretty well with very short tag names and the use of seat numbers instead of names.

- do you want to automatically validate if a HH is in a correct format? (xml schema)

Yes, this is a big plus

- do you want to be able to create other forms of representation automatically i.e. BB Code, back to PokerSites-individual Formats (XSLT)

Desirable but not essential. I'd imagine a single xml hand format would produce plenty of these tools through the community.

- should it only support flop/turn/river games (holdem, omaha) or others too (stud, 5 card draw?)

All is desirable, but let's get something working first. I think previous projects have fallen flat because of the difficulty of designing a standard. I'm a great believer in starting with something and then extending/rewriting it.

- should it allow references to earlier defined info? i.e. one currency tag ($,€,t) on top and only numbers later or seat info earlier with Playernames, and later only use seatnumbers to identify players?

If we're using a full xml schema with everything tagged out then human readability and non-xml parsing is pretty much non existent. In that case, seat numbers would be preferable. There should be a single currency tag IMO whatever format we use. So I think earlier referenced info could be avoided.

- how do you deal with different information, order, detail in Pokersites own formats?

Parse to a standard. For example, pokergrader makes a good point on having the amount put in on each action. As for missing information, we need to define "unknown" quantities in the schema to deal with these problems, and keep a minimal set of information (cards, board cards, seating, action type, $ put in, won $). Everything else (such as all-ins, winning hand type) can be extracted from the hand by code.

- regarding the creation of real-life-hhs: how much typing do you have to do?

Not sure what you mean.

- does tag order in XML matter to you? (what JavaNut mentioned)

Yes, very much. For three reasons:
- It makes it easy to simply traverse the nodes to build up a picture of a hand.
- It allows the intuitive insertion of other information in its correct place in the hand.
- Not everyone knows or is interested in XML. For example, rvg says he founded a 60 million company and has coded for 10+ years, yet knows little about XML. Average developers have no chance. We need to keep it so that string parsing still works intuitively line by line IMO. This also ties in with human readability.

[advis0r]

[ QUOTE ]
- regarding the creation of real-life-hhs: how much typing do you have to do?

Not sure what you mean.

[/ QUOTE ]

i mean when i have to write down a hand i played live, do i really want to write
<action type="bet" seat="2" amount="5.00">
(and figure out the seat id everytime)
or just
Hero bets 5

so the question is: how hard should it be for a human to create a hand history from scratch?

or: do you want to support live hands at all? (workaround: let them immitate a pokersite-format first and then convert to the standard format)

[pokergrader]

[ QUOTE ]
some questions that need to be answered:
- should it be easily readable by humans?
Yes
- does filesize matter? (bloated xml tags?)
Yes, but not that much. Given a universal specification it would be very easy to also come up with a super lossless compressed version for archiving purposes
- do you want to automatically validate if a HH is in a correct format? (xml schema)
I'm not sure XML is necessary, but if so, yes
- do you want to be able to create other forms of representation automatically i.e. BB Code, back to PokerSites-individual Formats (XSLT)
This is a job for 3rd party applications, not the hand history format
- should it only support flop/turn/river games (holdem, omaha) or others too (stud, 5 card draw?)
As long as their are universal representations for dealing personal cards, dealing community cards, check/bet/raise/call/ante, and showing down high and the low, the format should support every game.
- should it allow references to earlier defined info? i.e. one currency tag ($,€,t) on top and only numbers later or seat info earlier with Playernames, and later only use seatnumbers to identify players?
I think this type of trick would be advantageous if a super compressed version were to be created, but to me it takes away from the human readable aspect to save space that really isn't a problem anyway.
- how do you deal with different information, order, detail in Pokersites own formats?
This is an issue for 3rd party applications which convert hand histories to the universal format
- regarding the creation of real-life-hhs: how much typing do you have to do?
Probably the same you have to do now
- does tag order in XML matter to you? (what JavaNut mentioned)
Order should matter


[/ QUOTE ]

I understand how easy XML is to parse, but it is a lot of bloat. Any modern language can parse text lines with regular expressions just as easily.

A format like:

name : action : (if (RAISE), [raise to what amount]) : (if (RAISE|CALL|BET|*BLIND) [$ put into pot])

would be simple to parse and contain all necessary information:

pokergrader : CHECK

pokergrader : SB : 1
pokergrader : BB : 2
pokergrader : DB : 3
pokergrader : FOLD
pokergrader : BET : 50
pokergrader : CALL : 100
pokergrader : RAISE : 150 : 150

for dealing:

pokergrader : DEAL : Ah
pokergrader : DEAL : Kh

for dealing community cards:

<community> : DEAL : 4c
<community> : DEAL : 5h
<community> : DEAL : Ts

This isn't a complete format by any means, but I think simple is the key. And that format I just made up is more parser and applications friendly than any of the poker sites' hand history formats.

[rvg72]

So, one question should be, does the standard format need to be xml? There are some inherent advantages to doing it in xml but I'm not convinced either way at this point.

rvg

[Tickner]

Guy good discussion so far, I just got in to the office.

I agree with most of Phil153's answers to the questions.

About the offline hand histories.... when I mentioned it should support both online and offline hand histories I was serious, but trust me on this, its VERY easy to implement. Humans will never construct a valid XML document of a real life hand - thats a rediculas thing to ask somebody to do - and it isn't practical. What I mean was perhaps an attribute in the hand head tag (or whatever is agreed upon) that simply says online="true" and then if it IS online there should be information on the hand ID, the exact time it was played (in a standard format), the site it was played it, the table name, etc etc etc. Anyways these details are what we have to work on.

IF it is an offline hand, then we wouldn't have any real use for it here, but perhaps someday someday (me?) would create an online application that would allow somebody to reenact a hand they played at the casino or with their friends and get it into 2p2, FTR, or PHXML format.

Those of you who don't see the power of PokerHandXML won't understand why it's required.

1) Text files with Regular Expression parsing is usually quite slow and in efficient. All programming languages these days have EXTENSIVE support for XML. This is the future and we should stick to the new technology.
2) Formatted text files, while consistent, cannot be validated as easily as we could write a program to validate XML. The advantage to formatted text files would be that they are easily readable by humans (but that isn't the intention of this). Perhaps there could be a converter that will convert the XML into an easily readable human version.
3) If we do create the XML, I will take on the task of creating an online validator and official documentation etc etc for the PokerHandXML and of course will need your help and contributions. This is a team effort.

[ QUOTE ]
XML is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

[/ QUOTE ]

PokerHandXML opens the door to creating many more applications for poker hand histories than before. At the present time, everyone has to develop their own way to parse the raw hand history text, which is a big waste of time. If we can develop PokerHandXML, things would flow much easier and there would be more flexibility.

Some notes:

1) As a programmer I am not happy with the current HMSF. It does the job but it isn't true XML and is more so a hack to make programming easier.
2) I am VERY HAPPY that rvg is willing to co-operate with this project!! We should all be applauding him for that because his program is going to be playing a significant role in this.

[Tickner]

The question as to weather or not to use XML is a valid question. Personally I believe we should use XML. But I am open to hear others thoughts on this as well.

[Phil153]

One thing I dislike about pokergrader's implementation is that it's error prone. It doesn't force the developer to stick to a standard and deal with errors in consistency. You also have the problems of parsers getting erroneous information through things like ">" or ":" in player names, which some sites allow. By wrapping things in tags, and even moreso by having a validating schema, potential errors are lessened and spotted much more readily.

The other problem is extensibility in terms of:

- adding/inserting metadata and extra information into the hand.
- changing the standard.

So while pokergrader's implementation is very appealing, I'd have a hard time saying no to XML. As Tickner says, it's the data storage of the future.

[Tickner]

Guys,

W3Schools is GREAT for learning about XML and how to properly write XML documents, if you aren't familiar with XML you should check out this link...

http://www.w3schools.com/xml/xml_whatis.asp

If you are going to say no to XML, please at least read about and understand XMLs benefits and negatives so we are all on the same page.

[Tickner]

In that tutorial the proper SYNTAX of XML is defined: http://www.w3schools.com/xml/xml_syntax.asp

[TheIrishThug]

My thoughts are that the standard should be made to cater towards ease of programing. We know converters will be made to go from the standard to web and forum posting. So converting to a plain text readable form is really the same thing with out formating for colors or bold text.

To the same extent a 3rd party app could be made that did some of the work for a person to format a live hand. It's just a form asking for certain information, then the processor distributes the information to where it needs to be. This does bring up the question of unknown/forgotten information, but it's something to think about.

Validation sounds like a good idea, but I don't know enough about xml to know what that would entail.