The first public release of ONX is here! As predicted, it is version 0.5. Notice, please, that that is less than 1.0 - in other words, though this is a public, open, free, etc. project I would STRONGLY advice not doing anything with it yet. I am making it public because it is organized/complete enough not to be embarrassing, and so I can hopefully get some feedback.
Take a look at the version history file for what I've done so far, and what I have planned for the near future.
Enjoy :)
Download: http://sourceforge.net/projects/onx-opennovel/files/
Tuesday, March 23, 2010
Sunday, March 21, 2010
Progress, Celtx
I have made progress, and lots of it. Very nearly done with the initial public release - expect it tomorrow or Tuesday.
ONX is now completely compatible with yWriter and StoryBook, and I've made a lot of progress with tidying it up. I've also done a great deal to generalize everything in order to maximize compatibility with programs that aren't as common, don't exist, or I just haven't gotten to yet (less relevant).
I've started on Celtx compatibility. I have to say, it is a very different beast. I'm not personally a big fan, but maybe that's just because I'm not used to it. At any rate, it's not my place to pick and choose while writing this standard - it's supposed to universal or as near to it as is possible. Anyway, Celtx introduces some interesting problems, and if anyone is reading this blog I'd love some feedback on how to handle it. You see, Celtx does handle characters, location, scenes, scripts (which ONX will support, if not as fully as novels), etc. That's fine, and I've started added some elements based on their schema. But they also do production and pre-production stuff. Actors, storyboards (as in putting pictures in order, not putting scenes in order ... a somewhat subtle but very important difference), that kind of thing. So my question is, how much of that do I support? This is at its heart a NOVEL standard. But on the other hand, if people are using a certain program to write/plan their novels, do I just have to support that entire program? Or can I get away with sticking to just the novel-related stuff (and how do I define that)?
I'll be giving this some thought, and I'll make a decision eventually regardless, but as I said feedback on this one would be greatly appreciated.
P.S. BASIC Celtx compatibility will be in the initial release, but I won't be answering the questions posed in this post prior to release.
ONX is now completely compatible with yWriter and StoryBook, and I've made a lot of progress with tidying it up. I've also done a great deal to generalize everything in order to maximize compatibility with programs that aren't as common, don't exist, or I just haven't gotten to yet (less relevant).
I've started on Celtx compatibility. I have to say, it is a very different beast. I'm not personally a big fan, but maybe that's just because I'm not used to it. At any rate, it's not my place to pick and choose while writing this standard - it's supposed to universal or as near to it as is possible. Anyway, Celtx introduces some interesting problems, and if anyone is reading this blog I'd love some feedback on how to handle it. You see, Celtx does handle characters, location, scenes, scripts (which ONX will support, if not as fully as novels), etc. That's fine, and I've started added some elements based on their schema. But they also do production and pre-production stuff. Actors, storyboards (as in putting pictures in order, not putting scenes in order ... a somewhat subtle but very important difference), that kind of thing. So my question is, how much of that do I support? This is at its heart a NOVEL standard. But on the other hand, if people are using a certain program to write/plan their novels, do I just have to support that entire program? Or can I get away with sticking to just the novel-related stuff (and how do I define that)?
I'll be giving this some thought, and I'll make a decision eventually regardless, but as I said feedback on this one would be greatly appreciated.
P.S. BASIC Celtx compatibility will be in the initial release, but I won't be answering the questions posed in this post prior to release.
Realization
While mulling over some of the potential problems with the standard, particularly what to do about scene text, when I had a realization. I'm writing a standard here, not trying to force particular softwares to get along. It isn't my job to figure where to put scene content in StoryBook (which doesn't have scene content). It *is* my job to make sure the standard has a way to handle scene content, as some novel software does store that, just as it is my job to have a place to put StoryBook's "strands" - but not to figure out where to put those strands in yWriter or any other software. The standard is one big container capable of holding everything but not always holding everything.
The story changes a little bit when talking about the potential Universal Translator. That software, when I or someone else write it, will basically be a shell with plugins. Each novel software has a plugin, responsible for converting to ONX and from ONX. That way, in order to convert from yWriter to StoryBook (for example), the Translator uses the yWriter plugin to translate to ONX and then the StoryBook plugin to translate from ONX - there is no direct conversion between two different softwares, that's the whole beauty of the standard. Those plugins have a couple of different options on how to handle things. At a minimum, when converting TO ONX they should include ALL information their software stores (assuming the ONX standard is up to snuff and has a place for all of it, which it had better); when converting FROM - at a minimum - it should grab all information it has a place for and throw out anything it doesn't. But it can go a little further - it can do some of that hide-things-in-unlikely-places magic previously discussed, or it can do what I think is the best option. That is, to keep the ONX file somewhere. When converting back from their format to ONX (regardless of where the ultimate destination is), it allows the selection of creating a new ONX (if an old one doesn't exist, or the desire is to get rid of it), or it allows the selection of an EXISTING ONX file - in which case it UPDATES the ONX file with anything that has changed, and leaves everything else in place (including stuff that was never brought from the ONX file into the software, i.e. scene content in the case of StoryBook). That way, if the ultimate goal is to then convert it to another software (where it previously was, or of a similar type to software it was previously at), information isn't lost. Or even better, it allows for the selection of an existing project file in the destination software - only updating information there rather than creating a new project.
The best example is going back and forth between something like yWriter and StoryBook. Say you start laying out your novel in StoryBook - define characters, locations, timelines, strands, etc. After working on that for a while, you're ready to actually do some writing. So you use the hopefully-someday-created Universal Translator, which operates on the ONX standard, to convert from StoryBook to yWriter. Now you can work on writing in yWriter - actually put some words in those scenes of yours. You have access to all your characters, locations, etc. and everything yWriter does with them - no need to re-type them (of course you won't have access to 'strands' or other StoryBook specific stuff while in yWriter). But you come across a bit of problem and need to some more organization / re-ordering of your novel. Open up the Universal Translator and convert back to StoryBook (selecting the existing StoryBook file) - any changes you made to characters, location, etc. are available to you here in StoryBook, and your strands are still there and everything (some work might have to be done regarding *new* chapters/scenes as far as where to put them in strands; and of course scene content would not be available to you while in StoryBook). Make your changes, and convert back to yWriter. Your scene re-order, any character or location changes, etc. is now present in yWriter, you still have your scene content, and you are one very happy writer. And THAT is why I am working on this standard.
The story changes a little bit when talking about the potential Universal Translator. That software, when I or someone else write it, will basically be a shell with plugins. Each novel software has a plugin, responsible for converting to ONX and from ONX. That way, in order to convert from yWriter to StoryBook (for example), the Translator uses the yWriter plugin to translate to ONX and then the StoryBook plugin to translate from ONX - there is no direct conversion between two different softwares, that's the whole beauty of the standard. Those plugins have a couple of different options on how to handle things. At a minimum, when converting TO ONX they should include ALL information their software stores (assuming the ONX standard is up to snuff and has a place for all of it, which it had better); when converting FROM - at a minimum - it should grab all information it has a place for and throw out anything it doesn't. But it can go a little further - it can do some of that hide-things-in-unlikely-places magic previously discussed, or it can do what I think is the best option. That is, to keep the ONX file somewhere. When converting back from their format to ONX (regardless of where the ultimate destination is), it allows the selection of creating a new ONX (if an old one doesn't exist, or the desire is to get rid of it), or it allows the selection of an EXISTING ONX file - in which case it UPDATES the ONX file with anything that has changed, and leaves everything else in place (including stuff that was never brought from the ONX file into the software, i.e. scene content in the case of StoryBook). That way, if the ultimate goal is to then convert it to another software (where it previously was, or of a similar type to software it was previously at), information isn't lost. Or even better, it allows for the selection of an existing project file in the destination software - only updating information there rather than creating a new project.
The best example is going back and forth between something like yWriter and StoryBook. Say you start laying out your novel in StoryBook - define characters, locations, timelines, strands, etc. After working on that for a while, you're ready to actually do some writing. So you use the hopefully-someday-created Universal Translator, which operates on the ONX standard, to convert from StoryBook to yWriter. Now you can work on writing in yWriter - actually put some words in those scenes of yours. You have access to all your characters, locations, etc. and everything yWriter does with them - no need to re-type them (of course you won't have access to 'strands' or other StoryBook specific stuff while in yWriter). But you come across a bit of problem and need to some more organization / re-ordering of your novel. Open up the Universal Translator and convert back to StoryBook (selecting the existing StoryBook file) - any changes you made to characters, location, etc. are available to you here in StoryBook, and your strands are still there and everything (some work might have to be done regarding *new* chapters/scenes as far as where to put them in strands; and of course scene content would not be available to you while in StoryBook). Make your changes, and convert back to yWriter. Your scene re-order, any character or location changes, etc. is now present in yWriter, you still have your scene content, and you are one very happy writer. And THAT is why I am working on this standard.
What form will it take?
After progressing a ways toward the first "workable" version of this standard, I can now speak to what format the standard will take. Each release will contain 5 documents:
1) DTD XML Document Type Definition file
2) XSD XML Schema Definition file (duplicative purpose to DTD, but more detailed/formal)
3) Sample XML file (possibly more than one)
4) Version history txt file
5) Documentation - note that some documentation will be handled by comments in the DTD and/or XSD files.
How far along am I? Version 0.2 is done and version 0.3 is underway. All 5 mentioned documents exist in some form at present. I expect the first public version of the standard will be 0.5, even if it would make more sense for it to be version 1.0 :). This is an open project, and I might as well start by releasing it early on even if it isn't perfect.
1) DTD XML Document Type Definition file
2) XSD XML Schema Definition file (duplicative purpose to DTD, but more detailed/formal)
3) Sample XML file (possibly more than one)
4) Version history txt file
5) Documentation - note that some documentation will be handled by comments in the DTD and/or XSD files.
How far along am I? Version 0.2 is done and version 0.3 is underway. All 5 mentioned documents exist in some form at present. I expect the first public version of the standard will be 0.5, even if it would make more sense for it to be version 1.0 :). This is an open project, and I might as well start by releasing it early on even if it isn't perfect.
Friday, March 19, 2010
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.
Subscribe to:
Posts (Atom)