Comment 8 for bug 605324

On Sat, 2010-08-14 at 21:12 +0000, Andrea Gasparini wrote:
> * .svg with no metadata at all: we have to implement a "import"
> action, and so this case is currently not important. (BTW: it'd just
> be enough to set the whole metadata tag)

I agree with you about the "import" functionality. But I think this is
something to implement soon: currently an user must edit an SVG file
with a text editor before being able to use the file with A4. This looks
to me as a big blocker.

> * an .svg with a version attribute minor of the actual: should we save
> in the old format or convert everything to the latest? Perhaps we
> don't even want to read such a .svg... or not?

Backward compatibility is essential, in my opinion. If a user upgrades
his A4, all his old presentation *must* work, we can't invalidate all
the users' presentations every time we make a new release.

We must give the user the ability to read old format versions and
upgrade them. How to exactly handle this is something that we'll have to
decide for every release, when the format changes.

A question that we can start thinking on is: how many obsolete versions
we want to support for every release?

> * an .svg with metadata messed up, or somewhat we can't read or
> understand. In this case, we can raise an exception, and block the run
> of A4.

If the metadata can't be read, the user must be notified. We should also
offer a way for the user to use the SVG data (if not damaged too, of
course) ignoring the metadata, so that he can at least re-create the
presentation path and the animations.

> IMHO we'd like to implement the first case, and ignore the others (we
> can raise an exception, or read only what's really important in the
> second case)
> So, the case I see in which we want to add our version attribute is
> only the first.

There's an another case: an old A4 that opens a newer presentation file.
In this case, a message should be shown, but without letting the user
doing anything.