Quote:
Originally Posted by Jeff P
I agree that text files are far easier to work with.
However, one of the reasons I initially decided to parse the xml file was that upper management at Equibase assured me they were committed to using xml and that the basic structure of the xml would be permanent.
No. Not permanent forever. But permanent as much as any piece of technology can reasonably be expected to remain intact in this day and age.
There would always be a track node, a node for each race, and inside of each race node the individual scratch nodes for each of the scratched horses in that race, etc.
That was important to me. Before Equibase introduced the scratches and changes xml, I was parsing scratches and changes from the individual .html pages at the Brisnet Supertote site.
It seemed like Brisnet was constantly making html changes and breaking my code. (No bueno.)
A second reason I decided to parse the xml file instead of the individual files or .html pages was that the xml file contains scratches and changes for every track running each day.
That simplified things for me.
All I had to do was write a program to parse one simple xml file over and over each day.
For me this was actually easier than managing navigation events to and parsing events of (say) dozens of individual files or .html pages. (Separate files or .html pages for each of the many tracks running each day.)
Also, back in the beginning, upper management at Equibase told me the reason they were developing the xml file in the first place was to create a single source where not just horseplayers but everybody in the industry could go for scratches and changes constantly updated in something that approaches real time.
Then there's this, which is basically correct:
All of that was enough to convince me to invest in the coding hours needed to parse the xml file.
-jp
.
|
This is really interesting stuff, Jeff. Thanks for sharing!
