I took a look at SkeletonBinary.java in the Libgdx runtime to see how you were reading the binary format. I understand why you're reluctant to create binary loaders for all the runtimes, one tiny tweak in the format and none of the runtimes will read the new format (nor will the new code read the old format).
You should look into a meta-chunk schema, like the one used for SWF or media containers (jpg, png, avi, mp4, etc..etc...). Roughly, you use a byte sized ID for each meta chunk followed by a platform independant size integer for the chunk (numbytes). If the parser doesn't recognize the meta ID, then it can skip numbytes over the chunk and keep going. You can even use a version tag on the chunk to parse older versions... and you can simply subdivide the meta chunk into smaller chunks.
[byte metaID][byte version][DWORD size]
....[data]
[byte metaID][byte version][DWORD size]
....[data]
Versioning works as follows: always preserve the previous format/order of each previous version and append the new data onto the each of the chunk. This way a version 1 chunk could look like:
[byte EVENT_TYPE][byte VERSION_1][DWORD 48 bytes]
[string EventName: 36 bytes]
[int IntValue]
[float floatValue]
[string stringValue]
and version 2:
[byte EVENT_TYPE][byte VERSION_2][DWORD 52 bytes]
[string EventName: 36 bytes]
[int IntValue]
[float floatValue]
[string stringValue]
[int NEWVALUE]
Now, older parsers can still read the data because it would know to skip over 52 bytes for the chunk, skipping over the new value.
Newer parsers can still read the old data, because the chunk version is compared when reading each section:
if(version >= VERSION_1){
// read version 1 values
}
if(version >= VERSION_2){ // old parsers won't have this block
// continue reading version 2 values
}
Subdividing the data into smaller and smaller chunks makes sense too, as you can start the metatag IDs (enums) over inside each chunk. For instance:
[byte EVENTS=5][byte VERSION_1][DWORD numbytes]
[byte EVENTS_HEADER=0][byte VERSION_1][DWORD numbytes = 4]
[int COUNT = 2]
[byte EVENTDATA=1][VERSION_1][DWORD numbytes]
[string EventName: bytes]
[int IntValue]
[float floatValue]
[string stringValue]
[byte EVENTDATA=1][VERSION_1][DWORD numbytes]
[string EventName: 36 bytes]
[int IntValue]
[float floatValue]
[string stringValue]
This allows you to add extra container info to the EVENTS_HEADER, such as timeline data (or whatever) later on.
Writing
To write the chunks out, you would need to traverse the data depth-first, creating chunks and accumulating them in the higher containers. This is so you can calculate the numbytes for each chunk and subsequently for each container chunk.
When you create the new format, you should write out a 4 byte magic word as the first bytes of the header (eg. JIFF for jpegs). This is so you can read the first 4 bytes and determine if you are using the current binary format or the new meta-chunk format and not break your libgdx code (and so the editor can upgrade the formats).
Conclusion
Not anything that you would do anytime soon, but if you were to sit down and write binary loaders for the runtimes, it's a design that would help future-proof your efforts.
