Terminal error on loading XML
I have used Musescore 1.3 for years to read computer generated XML files from the Hebrew Bible. Version 2 gives a terminal error at line 11 column 52 of the first two scores I tried to read. The error is not terminal, since if I load anyway, it more or less correctly interprets the score. The line number is meaningless to me since it does not seem to correspond to anywhere in the score. What I do notice is that the eighth notes are separate instead of joined by a beam.
I would like to keep up with your software changes, but I may have to revert to the former version till this is repaired.
Thanks for your help.
Bob MacDonald
@drmacdonald
many additional scores at
https://drive.google.com/folderview?id=0BzkrfxErEx0Ca3lzQ1ZkMktROTg&usp…
| Attachment | Size |
|---|---|
| psalms-053.xml | 63.62 KB |
Comments
Seems there is some carriage return / line feed issue with that file, maybe that is why you don't find line 12 column 51.
Fatal error: line 12 column 51 Element supports is not defined in this scope.
Maybe that is also the cause for the error itself.
If I open it with Notepad++, I see on line 12:
</credit><supports element="accidental" type="no"/><part-list><score-part id="P1"><part-name/><score-instrument id="P1-I3"><instrument-name/></score-instrument></score-part></part-list>
column 51 is the end of that supports tag. That tag is supported (I can see it in several test files) but apparently not at that spot.
However, there is no need to revert, you can use 1.3 and 2.0 in parallel, they do peacefully coexist. On the other hand 1.3 just doesn't check for problems like that, so would ignore it, so you may be you're better off working with 2.0 and ignore that error too?
In reply to Seems there is some carriage by Jojo-Schmitz
Thanks for making me actually 'read' the message!
Line 12 is only defined to notepad (and so to me) when format word-wrap is off. Carriage returns in XML are a no-op. They should have zero impact on the reader.
Line 13 in my file is the first direction tag. It contains Hebrew text in extended HTML. But this is not a problem. I did a test with the Hebrew suppressed and got the same error.
'Supports' is a well-defined tag that ends itself
As far as I can see, the tags are all correct, but maybe it is out of context.
I removed the supports tag from the generated code and the file now loads without error. So perhaps regardless of the line number, the message was correct. I don't remember why I had the supports tag in - I think it was from an experiment with another program that I could not use because the XML and extended HTML support was not adequate.
The new program v2 takes a long time to load compared with version 1:3 - 15 seconds. I turned off the sample score and start centre and things speeded up dramatically.
I see also that my titles, subtitles and credits are no longer supported the same way. I guess I will have to reread the XML documents for this version. Is there a set of changes online re XML?
In reply to Thanks for making me actually by Bob MacDonald1
I first opened in in vim and saw a lot of ^M. vim usualy doesn't show them, regardless of whether a file is in DOS or UNIX format. Maybe this is in (old) Mac format?
"supports" is well defined, but seems out of context here, at least MuseScore thinks it is, and it does use an XML validator, so I think is right on that. But we'd need Leon Vinken, our resident MusicXML guru, to confirm...
Docs are on http://musicxml.org
MuseScore 2.0 switched to MusicXML 3.0, MuseScore 1.x was using an older version, as far as I know.
The explanation for the error is that MuseScore 2.0 does XML schema validation, which MuseScore 1.3 did not do. As a result, 2.0 sometimes complains about MusicXML files that were imported without reported errors by 1.3. In most cases, after answering "yes" to the question "Do you want to try to load this file anyway?", the file still imports correctly.
The error in your file is that the "supports" element must come before the credits. Furthermore, it must be a child of the "encoding" element, which must be a child of the "identification" element. Corrected file is attached.
Still have to investigate the issue with the title etcetera, but my first guess would be that it is probably caused by the missing page size specification in your file, which I suspect causes the texts to be present, but placed incorrectly.
In reply to The explanation for the error by Leon Vinken
Thank you for this clarity. The identification section is easy to include in my program that generates the xml. I will also include a page size and see if it fixes the title etc.
In reply to Thank you for this clarity. by Bob MacDonald1
I put in the page parameters and the titles etc have appeared. Also the identification tag etc was accepted. My only difficulty is that the Hebrew font is a bit of a disaster. The default fonts in version 1.3 were very readable. I was able to put in these additional defaults
word-font font-family="SBL Hebrew" font-size="10"/
lyric-font font-family="FreeSerif" font-size="10"/ /defaults
looks much better now.
thanks for all the help
Bob
In reply to I put in the page parameters by Bob MacDonald1
You're welcome, Leon.