Submitting XML files
I have a feeling this has no answer, but just in case someone else has had the problem ...
Our scorer is extracting from BBO and processing through EBUScore. Uploading to Bridgewebs goes smoothly, but the Submit to EBU hits a file parsing error. But when they send the XML file to me, it uploads and submits with no problem.
Any thoughts?
Comments
Steve
I think the scorer is using edge. I used chrome.
Steve
It sounds as though you think Edge is the problem?
The scorer doesn't use Chrome and I gather Chrome has recently made it more difficult to download PBN files.
Steve
This is a very strange issue you have raised.
I would set up is a screen sharing session (Teamviewer free is what I use) where you can see what the scorer can see on their screen.
I would suggest that you download a copy of the (free) Microsoft XML Notepad, which is what I use for viewing (and editing if necessary) XML files. Then try opening the failing xml file using the XML Notepad. A file will not open in XML notepad if there is a basic XML error , but obviously it can't check to see if the parameters are the ones required by the receiving system. If it does open you can have a look at the data (click on the + signs in tree view to open up lower levels) and see if it appears to hold the full event data, and try submitting it again.
If this doesn't succeed, the next thing I would do on the scorer's PC is to retrieve the file that was sent to you (from the sent mail), and then try loading this to the EBU.
If it still fails, the last thing (clutching at straws now) would be to check which account was logged in to the EBU when uploading, and then (if it's different) for you to log in on the scorer's PC with the account you used successfully, and try again to upload the file, and see what happens.
Based on your description, I see the most likely issue to be human error, though there is no way of 'proving' this, which is why I would use screen sharing to see exactly what is happening on the scorer's PC.
I hope this helps. If it gets you further forward, but still short of a solution, by all means post an update of what you have tried and found, and we can see if we can make further suggestions.
Peter
I’ve used a variety of browsers, debatably it seems to happen less when I use Chrome but that may be coincidence.
However simply opening the p2p upload file in note, entering a space anywhere, taking in out and saving the file then causes the file to load or submit.
I discussed this with Jonathan who gave me these this top as he had discovered it too.
Again not a full solution but a workaround.
Could this be a character encoding problem? i.e. the XML file is not encoded in utf8?
Do any of the player names in the file include accents?
(Perhaps re-writing the file forces it to use utf8)
Not in my files.
I haven't actually used BBO extractor but have worked with its creators, John and Mirna Goacher.
The issue here may be that in order to support the replay feature in Bridge Solver Online, accessible via Bridgewebs, there are .lin elements embedded in the XML (.lin being the BBO format). These are not part of the USEBIO standard so will cause a parsing error if submitted to the EBU.
Looking at the version here:
https://dds.bridgewebs.com/bbotoxml/bbotoxml.htm?p=1
there are separate XML downloads for EBU and for Bridgewebs and I imagine the EBU option will NOT include these problematic elements.
It's definitely worth including them though for Bridgewebs since it adds a lot of value to the analysis.
Tim
...
...
It's true that the P2P upload will fail if the file contains the lin elements inserted for Bridgewebs by BBO Extractor/BBOtoXML. However, the original post at the top of this thread implied that it's an upload from EBUScore that fails. EBUScore does not include these elements in its XML output files, and for that matter cannot import XML files containing these elements. It can only import the UMS version of the XML file produced by BBOtoXML, which is also uploadable directly to P2P.
John
John is right - I have already flagged this with the EBU staff, that It just needs a minor update of tags in the downloaded DTD file to process the XML with the play data. I have my own private updated DTD version which handles both XML types and even better, that update obviates the complication of separate XML files and accidentally picking the wrong one for Bridgwebs upload etc!
Jeff - Does this mean EBU Score would be able to export the play data in its XML output, or would it just import XML files containing play data without passing it through ?
At present it would not export the play data.
I have just had this problem for the first time. Inserting, removing, and deleting a space didn't work.
XML Notepad wouldn't open the file and would not parse the space after: 'played by> ' which had been inserted by EBUScore for every traveller entry where a board had been Passed out.
In the USEBIO description it says 'played by> ' is not needed. I tried deleting every occurrence of 'played by' for a Passed out score but this introduced a random problem somewhere else
In the end I replaced 'played by> ' with 'played by>S ' wherever a board had been Passed out.
This parsed correctly and uploaded successfully to myEBU.
It may be that EBUScore needs looking at for this.
Peter Bushby Suffolk
When replacing data like this, are you manually searching through Notepad and correcting it when found, or are you using the 'Replace' function?
I use replace (sometime Find & Replace depending on the app being used), quite a bit and it make mass changes a doddle - worth a look if you are not doing that already :)
Thanks Martin that's a good tip
Peter Bushby Suffolk
No probs :)
I just checked and the latest EBUScore does not plant the PLAYED_BY (or LEAD or CONTRACT or TRICKS) for pass. You can check that the file is syntactically correct by the validation tab at: http://www.usebio.org/
Sorry Jeff but I just ran it again then used your link to check syntactical correctness.
I got: "Invalid file given! File does not parse. Check your tags. Try Again"
Editing the Usebio File and searching for 'Pass' I get:
(with less than and greater than removed so that it would display in this post)
"TRAVELLER_LINE
NS_PAIR_NUMBER>5</NS_PAIR_NUMBER
EW_PAIR_NUMBER>14</EW_PAIR_NUMBER
CONTRACT>PASS</CONTRACT
PLAYED_BY> <PLAYED_BY"
Peter Bushby Suffolk
Are you on the lastest version,Peter? EBUScore 1.2.6 ?
I just tried it and it appeared as below:
1
7
0
2
8
TRAVELLER_LINE NS_PAIR_NUMBER>1</NS_PAIR_NUMBER EW_PAIR_NUMBER>7</EW_PAIR_NUMBER SCORE>0</SCORE NS_MATCH_POINTS>2</NS_MATCH_POINTS EW_MATCH_POINTS>8</EW_MATCH_POINTS /TRAVELLER_LINEJeff
Curious
Yes I am on 1.2.6..
This was an event merging two sections from BBO,
result extracted into EBUScore using Chris Chambers' BBO Scorer.
Peter
Peter Bushby Suffolk
Jeff, I can confirm what Peter says. I've been doing some comparative testing of our own software and in the course of this imported an XML file from Bridge Club Live into EBUScore Pairs 1.2.6 and then generated a P2P XML file from EBUScore. The input file contains a traveller line with "PASS" in the CONTRACT element and 0 in the SCORE element. It does not contain PLAYED_BY, LEAD, etc.
The output file generated by EBUScore does contain a PLAYED_BY element for the corresponding traveller line and this contains a single character. The character looks like a space character in Notepad, but on examination with a hex viewer it can be seen that the character is actually binary zero. This is the cause of the validation failure. If the character is edited out the file validates ok.
I observe that when a PASS score is manually input in EBUScore (by inputting 0 on the Enter Scores page), EBUScore generates a traveller line without a CONTRACT field. Perhaps it's the presence of the word "PASS" in the CONTRACT field of the imported XML file that is causing the issue.
I'll email you the XML files.
JohnG has sent me the associated files and he is right on the cause.
When EBUScore normally has a passed out hand, it stores Contract, Lead, Declarer as empty strings and when it writes the XML file, it tests Contract and if it is an empty string, it just plants the Score 0 element alone.
When a file is imported, the Contract has been set to PASS as well as Score set to zero, and the import stores that as the Contract, but doesnt store a declarer or Lead as there is none present. Consequently, when it outputs the XML for an EBU upload, it plants a Contract PASS as well as a Score 0. It also plants a Trimmed of spaces value of Declarer and Lead if their length > 0. The trimmed Declarer is an 'uninitilialised string of 1 byte so plants its strange strange character of one byte, The Lead is held as a 1 byte index to a blank string hence it is not planted.
Fixing this in EBUScore would be simple - If Score = 0, then just record that at import or output or both. However, in my view PASS is NOT a contract so the line in the import file (presumably produced by JohnG?) should not be present in the imported XML. That would obviate the problem, unless some other utility is using the Contract field in its XML parsing?
There is no particular guidance on this in Usebio1.2 spec other than
"These provide information about how the hand was played on this traveller line i.e. what the contract bid was, which player made the contract, what the lead card was and how many tricks were made." IMO in the case of PASS, there is no Contract (and no associated lead or Declarer).
As a general point, the ImportXML in EBUScore was a bit of an addon intended for people who had (accidentally) deleted their event history entry and also to read in an event from another scoring program. It doesnt have the movement information, so there can be problems down the line eg importing a teams and trying to get the seating lineup which based on the stanzas in the Move history. It also tends to accept XMLs generated by EBUScore, but may well fail on XMLs generated by other programs eg It looks for a Section and Session entry, which are often omitted by other XML generators if it is single session section event! There are a few other things such as it assumes an even number oif tables and mars pairs as missing, whereas some XML generators give unbalance NS/EW pair numbers, which leads to the Import ending with the wrong number of tables. I guess the whole Import procedure could use a revisit to attend to these (not bugs) but issues?
The file was not one of ours, it was from BridgeClubLive via brianbridge.net. However, BBOtoXML would also have put "PASS" in the CONTRACT field. I would be a bit reluctant to remove the CONTRACT field for a Passed hand without knowing whether it would affect any downstream software.
Does the extractor produce two different xml files? and> @jgoacher said:
That's a very reasonable point, except that in this case we know that leaving it in is affecting downstream software.
The problem was originally highlighted by Peter, and he was using BBO Scorer. So, that's at least three programs generating XML files that put PASS in the CONTRACT field (BBO Scorer, brianbridge.net, BBOtoXML), whereas we currently only know of EBUScore that has a problem with it. When referring to downstream systems I was thinking mainly of results websites - Bridgewebs, Pianola, Bridgcloud etc. I think it makes more sense to just change EBUScore.