Mission Statement

First, a disclaimer: the idea for ONX came from a friend of a friend (coworker). He will receive credit if he wishes it.

My coworker is working on a project to branch StoryBook with the idea of integrating yWriter - basically he wants to be able to import and export yWriter files so that StoryBook can be used for planning and yWriter for writing. On hearing this, his friend (who uses both softwares) suggested that he should take it a step further and create a standard capable of storing data from ALL of the major novel writing/planning softwares. My coworker thought that was a decent idea, but decided to take a limited focus for at least the first revision of his project (based on the why of his project, which reasons shall remain his own). On discussing his project with me, I decided to take up the mantle of the universal file standard.

In keeping with my coworker's friend's original idea, the standard is to be XML. It is to be called ONX - Open Novel XML. Or One Novel XML. Or Open Novel Exchange. Or One Novel Exchange. Haven't decided yet. Maybe it's all of them :).

Some of this project will be straightforward. Novels contain chapters and chapters contain scenes, locations and items and characters abound. As long as the standard is flexible, it should be able to contain that information (and general project info such as author, progress, etc.) in a way that can be converted to/from any software.

Some of it will be a little more difficult. Take the yWriter/StoryBook example. Both have all the basic stuff, easily dealt with (one in the form of a sql database, one in an xml file) - the standard will be somewhere between them and capable of representing both. StoryBook has strands where yWriter doesn't, but that is also easy enough (the standard will include strands, but they don't have to be used, and would not be in the case of a project that originated as a yWriter project and never touch StoryBook). But what of scene content? yWriter is actually used to write a novel, StoryBook is only for planning. Obviously you place the content of the scenes or names of files containing the content within the onx file as an optional element, but where do those go when you convert the onx file to StoryBook?

The only way this standard will ever work completely is if it were to be adopted by all the softwares. In the meantime, we can do some work arounds. For example we can store scene content in StoryBook as unused Locations (the content going in the Description field, one of the other fields used to identify which scene it belongs to). The problem with that solution is that the Description field in StoryBook has an 8192 character limit. [Sidenote: if anyone is thinking, "why not just use the scene Summary?", the answer is that we still want to have that available for a summary of the scene ... we could create unused scenes instead of Locations but it amounts to the same thing and in StoryBook Locations are the smallest (contain the fewest fields), and will be less intrusive when working on the project. Now, about that character limit - the solution is to use multiple Locations per scene, when needed, using one of the other fields for chapter id and one for sequence.

An alternate solution to the problem is to only store file name (with the assumption it's in the same directory as the main onx/StoryBook/whatever file) for scene content. This would of course mean that an onx project would not be self-contained, and that file location would still have to go somewhere, but it would be easier. You certainly wouldn't need multiple Locations per scene, and you could even hide it somewhere like in the scene Summary by using some special characters to identify that information (this would slightly reduce the number of characters available for the summary, and is a may be considered more intrusive).

A final option is to always keep the .onx file around and use it as a go-between. That is, when importing, only relevant things are imported, when exporting, you may choose an existing .onx file and changes will be made to it rather than writing from scratch, thus preserving anything not compatible with the exporting software (i.e. scene content in StoryBook).

I have yet to make any "final" decisions on how to address that problem and similar (or anything for that matter) and am open to suggestions.