I have realised that musicXML does not correctly transfer articulations, dynamics, the display of the accidentals and pedal markings.
Is musicXML still not reliable?
A. A screenshot from Dorico 2.2
There have been plenty of threads about this recently. Just search for them!
For the record: no, MusicXML export from Dorico is NOT reliable.
The other way around is pretty good, though, with the necessary caveats.
“MusicXML” is not a thing, it is just a file format, so you can’t describe it as “reliable” or “unreliable”.
The issue is that Dorico doesn’t export everything in the score to MusicXML yet.
OK, thank you!
“MusicXML” is not a thing,
I wonder if Michael Good knows that. 
The “MusicXML specification” is a thing. A “MusicXML file” is a thing. “MusicXML” is not a thing (though it is a trademark).
Never forget the difference between a thing, the name of a thing, what the thing is called, and what the name of the thing is called (ref: Charles Dodgson, a.k.a. Lewis Carroll).
OK.
The correct title of the thread would be:
How reliably Dorico treats musicXML specification: a comparison of a Dorico file with its musicXML file exported by Dorico opened in Dorico and Finale
I have realised that musicXML does not correctly transfer articulations, dynamics, the display of the accidentals and pedal markings.
Is musicXML still not reliable?
The paragraph above should be rewritten as follows:
I have realised that the musicXML file exported by Dorico does not correctly transfer articulations, dynamics, the display of the accidentals and pedal markings.
Is musicXML produced by Dorico still not reliable?
viewtopic.php?t=132937#p719804
Thank you! I now know the reason!
Once again, the other way around is pretty reliable. Depending on the preferences which have been set, an XML exported from Finale into Dorico displays all custom beaming, articulations (except the fermata which, for some reason, is considered to be articulation by Finale), dynamics, lyrics, slurs, tempo markings and even some text, although pizz. and arco didn’t come across.
Yes, it is pretty reliable.
However, still not perfect:
The problem is because Finale does not have a real tremolo…
Anyway, interchanging sheet music is still not perfect,
Actually in my last project, all the tremolos came out perfectly. Perhaps it has to do with an improved XML export from Finale. In any case, this went for both tremolos on stems (an articulation in Finale) and tremolos between two notes.
My test from Finale v25 to Dorico 2.2
The followings are not correctly transferred:
No. 10 is the limitation of Finale
Concerning No. 1 - 9, I do not know why they do not work as expected.
Dorico does not forward text that does not have a syntactic label in XML.
That is why fingerings forward from Finale (because they are marked as fingerings in XML) but not from SIbelius (if I correctly recall how Daniel explained it).
If it’s just text with no assigned function in the XML code, Dorico omits it.
I believe there’s now an option for that under Preferences > MusicXML import
That won’t cause everything to be imported, however. Some things like pizz./arco are not specified in MusicXML as text, but rather using elements like
<technical>
, which Dorico imports only incompletely at the moment. There is always more work for us to do on every area of the program, and MusicXML import is no exception – though it happens to be considerably more advanced than Dorico’s MusicXML export.
Any news about Dorico MusicXML import and the <technical> elements like:
<open>
<snap-pizzicato>
<stopped>
<up-bow>
<down-bow>
<harmonic>
These are playing techniques that already exists in Dorico so it shouldn’t be hard to import them from MusicXML files. But I can’t get it work in Dorico 3.5. And for all text playing techniques, like pizz. and sul tasto one should be able to use the <other-technical> element. But it won’t seem to be implemented either.
I wish you will implement in the near future. Until then my workaround is to export those playing techniques as the direction type <words>, so I can identify them, and then exchange them manually to the corresponding playing technique. But it’s time consuming and annoying.
Xml import/export has not yet moved to priority status, so there haven’t been any major changes.
Hopefully if that is correct (I don’t know personally) this will change. For Dorico to be fully defined it must be so internally (the relationships of different features to each other must be known) and externally (a user must know how Dorico will or won’t be able to assist them in their workflow).
Excuse-me, I have to make a statement here. There have been massive changes in XML export during the Dorico 3 cycle. At that time, it was really important to me, and things have really changed. Now we’re talking about details. Not to say it’s not important, but we’re far away what was possible during the Dorico 1 and 2 cycles (especially for exporting).
Marc, I didn’t mean to imply that there had been no development at all; what I was saying is that it has not gotten the major overhaul that is eventually promised. In other words, full export and full import of all of Dorico’s supported feature set in line with XML 4.0 spec. That hasn’t happened because it has not been moved to the primary priority for the development cycle. (I say that with complete neutrality; just as an observation.) Admittedly, I had forgotten how rudimentary XML support was at the beginning, but that was also literal years ago.