Poker Hand XML

[Triggerle]

I think we should aim for an XML format that can completely replace the current hand history format. It should eventually be able to let poker rooms switch from their current format to this and it should be possible to reconstruct any given poker room's original hand history files from the XML. This format should be designed with a 10year+ lifecycle in mind and who knows what uses it may see.

It should not limit itself to only a subset of the information we get in today's hand history files. Chat is obviously important to some (many) people and can even be part of the play, so I see no reason to exclude it.

[iwannawon]

I'm not a programmer but as an 'end user' of HHs w/ web converters and PT, etc I'm interested in the subject and have checked in and followed most of the discussion so far hoping to learn something new. I'm still curious/confused what each of you think the xml standards purpose(s) will be. What is the process/workflow?

I originally thought, the purpose of the xml version would be to, over time, get all sites to use a common format. While a bit less user friendly to read, it isn't difficult and we'd all get used to it. With more consistency, I can see more/better replayers/HH viewers being created so native files may not need to be read as often. Web sites/software could easily (I assume) parse out the xml tags so the final view looks similar to what it does now. If this is the case, it seems it would have to contain all information (chat, etc). There would, eventually, not be 2 files to decide to keep one or the other. It would be the native file.

If it isn't meant to be the source data, what applications would use it? Most of the common ones already import the major sites HHs. Why would someone convert a supported file to xml? Without knowing more about specific software that you're hoping to help with xml, I don't see why i'd ever convert. If software exists that doesn’t support a ‘standard’ HH, why would they create a new import method for xml rather then just start supporting the native file? It looks like some of you assume someone will make/maintain a dll that all companies will have to use that will convert all the native files to xml which they will import. Why assume the middle step? If the xml is complete it will only be temporary.

Even if its intent is more focused now, why limit it, seemingly, just for filesize? Each year compression, access speeds, and hd capacity increase. I’m not saying get sloppy with it, but why intentionally limit it when its uses haven’t been fully determined yet. Whatever you leave out will be handled differently by each site as the text HHs are now and this effort will seem a bit wasted.

Finally, why is there a <texasholdemhand> tag? That seems different than the rest of the ‘generic’ xml structure. Why then have ‘round id’ and just hardcode ‘flop’ if it’s already known to be holdem. Earlier posts showed things like gametype=holdem, etc that seems more flexible. All the parent tags will be the same for all games at least. Or just make it ‘holdemxml’ and get rid of the root tag (pokerhandxml) altogether. (not actually being serious, just trying to make a point).

Sorry, that got a lot longer than I intended. Again, just asking to learn, not to criticize.

[OrcaDK]

[ QUOTE ]
Is the PokerHand XML format supposed to replace hand histories so that the user can delete the original format or is the PokerHand XML format going to be primarily used as a well defined format for all poker applications to use?

From my point of view its the latter. I would still keep the original hand histories. In PT3 for example, we could have an option to import from the PHXML format or export to the PHXML format for third party applications; however, this will not replace the native hand histories.

Therefore, I think chat is not needed and should be optional to the end user or third party software. Thats the beauty of XML...

[/ QUOTE ]
This is actually an excellent point that I'd forgotten. In my view, this format is primarily for exchanging basic hand histories, not for storing them. Thus chat should not be included. If people want to transfer everything in the hand history, they should transfer the original files themselves. In almost all uses of this format the applications will only be utilizing the actual hand actions.

[Triggerle]

[ QUOTE ]
This is actually an excellent point that I'd forgotten. In my view, this format is primarily for exchanging basic hand histories, not for storing them. Thus chat should not be included. If people want to transfer everything in the hand history, they should transfer the original files themselves. In almost all uses of this format the applications will only be utilizing the actual hand actions.

[/ QUOTE ]

So a third party project hand replayer would not be able to use the XML format then if chat is important to its users.

The developers would have to write their own hand history parsers for all sites they want to support. This sounds very much like the situation that spawned the PokerXML idea.

[APerfect10]

[ QUOTE ]
[ QUOTE ]
This is actually an excellent point that I'd forgotten. In my view, this format is primarily for exchanging basic hand histories, not for storing them. Thus chat should not be included. If people want to transfer everything in the hand history, they should transfer the original files themselves. In almost all uses of this format the applications will only be utilizing the actual hand actions.

[/ QUOTE ]

So a third party project hand replayer would not be able to use the XML format then if chat is important to its users.

The developers would have to write their own hand history parsers for all sites they want to support. This sounds very much like the situation that spawned the PokerXML idea.

[/ QUOTE ]

No, my proposed solution was to make it optional. If say, they wanted to export their hand histories out of PT3 for use with such program, there would be an option they could tick that would create the <chat> tag. I think by default this would be unchecked though because 99% of programs do not need it and it would just bloat the XML file.

[Shoe Lace]

[ QUOTE ]
If say, they wanted to export their hand histories out of PT3 for use with such program, there would be an option they could tick that would create the <chat> tag. I think by default this would be unchecked though because 99% of programs do not need it and it would just bloat the XML file.

[/ QUOTE ]

This seems like a reasonable approach, and this could even solve the reads/stats problem with some extra thinking.

If a third party app requires this information then that third party app would specifically say "you must enable x export features in PT/HM to include chat/reads/stats".

At this point PT/HM look into the original HHs to append the chat.

Stats and reads would be a little more tricky though, but nothing insane. PT/HM users would need to "save stats" after the session on any hands they want to export before they gather more hands on players. This info should be stored in a separate file (which would be appended to the PokerXML hand if this export feature were enabled).

Reads could be added any time, directly through the PT/HM interface on a per hand basis or during the time of the export and would be stored in the same file as the stats.

End user gets:

1. A lot of information.
2. An easy to use system to include this information.

Developers get:

1. A non-bloated file.
2. The ability to work with information they wouldn't have had previously (stats/reads) which could lead to unexpected decent apps.

[Triggerle]

Thinking about the chat thing I just noticed something: What about disconnect messages? These significantly influence how the hand plays out.

Regarding an optional chat tag I guess many (myself included) could live with this compromise, although I still dislike the idea of throwing away information and thus having less information in the PokerhandXML than in the native HH formats.

[mikechops]

I'd prefer optional to mean that a developer is free to not support it, rather than he must support it and the user gets the choice as to whether he wants to export it.

I've written 5 parsers in my time. I'd be quite happy to knock up a convertor for a lean and mean spec. If I've got to go back and add chat... well I'd be less happy about it. I mean it's not the hardest thing in the world to do, but it would be pretty tedious - there's all kinds of weird places chat could happen - and it isn't exactly motivating to be forced to do something that I'm convinced will be pretty much always ignored.

[Shoe Lace]

[ QUOTE ]
I've written 5 parsers in my time. I'd be quite happy to knock up a convertor for a lean and mean spec. If I've got to go back and add chat... well I'd be less happy about it. I mean it's not the hardest thing in the world to do, but it would be pretty tedious - there's all kinds of weird places chat could happen - and it isn't exactly motivating to be forced to do something that I'm convinced will be pretty much always ignored.

[/ QUOTE ]

Parsing an xml file is a much different animal than a typical HH.

If chat happens to be included and you have zero support for chat in your app then nothing will have to change on your end.

If however down the line, you implement a feature which includes chat it would be as simple as reading a specific element type. This element does not directly interfere with what you were reading before you decided to add chat support.

[mikechops]

I meant writing the convertor code for the .dll is going to be significantly more complicated if we have to include chat as a requirement.