Questions on upgrading file formats for OO3

[Timothy J. Wood]

   We've been going around in circles on this one internally for quite a 
while now, so we thought it would be a good idea to ping the list.

   Some of the issues:

	- OO3 can read/write OO2 plist formatted files as well as its own XML 
format
	- OO3 can read OO2 XML files, but will upgrade them to the new OO3 DTD
		- This will produce a upgrade warning panel like many of you have 
seen between minor OO2 format changes

	- OO3's format is richer than many of the formats it can write to, so 
some features might be dropped on write (attachments, for example)


   Say you open up a OO2 file.  You might want it upgraded to OO3's 
native format and you might want to leave it in the source format any 
number of valid reason.  For example, with legacy formats (say, MORE), 
users might want to upgrade to OO3's native format, but for 
compatibility formats (OPML, OO2) they might prefer to keep that format 
so they can share with users running other outliners.

   When opening a non-OO3 file we can:

	- Make the document untitled, forcing the user to pick a new file to 
save to.
		- This fine for import-only formats, but for import/export formats, 
this would be really annoying

	- Set the document title to Filename.xmloutline so that when the user 
saves, they'll get a native file
		- Fairly transparent to the user
		- This avoids clobbering the original data, leaving it as a backup.
		- For formats like OPML that are used for sharing this would be 
really annoying
		- User might be unable to distinguish between the two files in Finder 
and accidentally open the old one
		- We could also optionally delete the original file the first time 
the user saves with the new format (with a prompt)

	- If we are able to write the source file format, just open the file 
w/o any warning panel
		- For advanced users for compatibility formats, this is really nice 
since you can just open/save the document
		- For novice users, they might use some feature of OO3 that can't be 
stored in the destination format.
			- Prompting them on save might be bad since they may have put a 
bunch of work into their document
			- Prompting them on open that they won't be able to use the extra 
features would be annoying

	- Pop up a panel giving the user the option to upgrade the file or 
leave it alone
		- Maybe store their answer in the resource fork
		- Not really nice for people using files in CVS or other non-HFS 
aware situations, though.

   When saving:

	- At a minimum, we want to prompt the user if they are using features 
that aren't supported by the target format
		- Even, this could be annoying... say you export to plain text; it 
would be annoying to get a warning that images can't be saved in plain 
text.
	- Might be nice to warn them the second they do something that isn't 
supported, but this would be easy to get wrong, leading to tons of 
annoying panels.



   I'm hoping to avoid some really complicated solution here, so people 
have comments on how often they use sharable formats and whether/why 
you'd want to keep using the OO2 format (sharing with other users on 
your network, for example?), that will help us come up with the "least 
bad" solution here :)

   Thanks!

-tim