Presentation files should contain version information

I believe this bug is important enough (and pretty easy to fix) to be milestoned for 0.03, given that 0.03 will be the release we will implement the editor. Therefore, I'm milestoning it.

Wouldn't it be better to version the metadata format instead?
Two versions of the editor could use exactly the same metadata, not to mention that there could be different implementations of the editor and that one could write a presentation with a text editor.

Also, since metadata will be transitioned to XML, it would make sense to begin versioning metadata once we have them in XML.
This will be more robust since even after a total redesign of the metadata, the version attribute could reasonably put in the same place.

Well, since a presentation is just a SVG file with one more <metadata> tag, I don't see any difference between versioning the metadata or the presentation itself. So, yes, we could version the metadata. :-)

I left this one open because the code in the "new_metadata" branch does not write nor verify the "version" attribute.
Am I wrong?

oh, right (i'm just working on it :P )

Before closing this one, I think the editor should also add/set the version attribute of a file when saving.

mmm, I'm thinking what cases should be handled for saving the version attribute.

I see the following:
* .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)
* 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?
* 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.

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.

Let me know if you thought about other possibility not mentioned (it's late, and I can easily lose some) or if you think it's better to behave differently.

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.

I see the following cases when opening a file:
1) no metadata at all: import the file (see bug #618162)
2) unreadable metadata, no version attribute, miscellaneous exceptions: show a warning box, don't open the file
3) current version: open it :-)
4) known old version (that we can handle) open it; this may need a separate parser for old versions, unless the old version is a subset of the new one; of course we can't implement this one now
5) unknown version: show warning that information may be lost, try to open it

When saving:
- only option is to save in the current version for cases 1, 3 and 5
- in case 4, the easy thing is to wipe out the old metadata and save in the current format, and this is what I would do, possibly showing a warning that the file may be unreadable by older versions of the program
- optionally we may want to export in an older version but this is very complicated and I wouldn't think of it until we have a widely deployed version (read: inclusion in a distro)

<email address hidden> <1281859524.1571.17.camel@nitrox>
Message-ID: <email address hidden>
X-Sender: <email address hidden>
Received: from dynamic-adsl-78-13-71-68.clienti.tiscali.it [78.13.71.68] with
 HTTP/1.1 (POST); Sun, 15 Aug 2010 12:14:25 +0000
User-Agent: RoundCube Webmail/0.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

On Sun, 15 Aug 2010 08:05:24 -0000, Andrea Corbellini
<email address hidden> wrote:
> 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.

Of course, I don't think that someone disagree with this.

>> * 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.

Yes, but that's not what we're talking about.
The problem is "when set or add a version attribute", and imho that's not
the case.

>> * 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.

As above, we can think this case into the first (new svg data)

> 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.

Here, too, we don't have to set or add version attribute.

On Sun, 15 Aug 2010 10:32:14 -0000, Andrea Gualano
<email address hidden> wrote:
> When saving:
> - only option is to save in the current version for cases 1, 3 and 5
> - in case 4, the easy thing is to wipe out the old metadata and save in
the
> current format, and this is what I would do, possibly showing a warning
> that the file may be unreadable by older versions of the program
> - optionally we may want to export in an older version but this is very
> complicated and I wouldn't think of it until we have a widely deployed
> version (read: inclusion in a distro)

Not clear: in cases 3 and 5 do we want to save version attribute?
For case 4: ok, but I'd handle this just when we'll have a new version.

The version should be always put in a presentation file. Otherwise, how can A4 know the version of the format?

>Not clear: in cases 3 and 5 do we want to save version attribute?

In case 3) the version in the file is the current one, so overwriting it or not makes no difference.

In case 5) you can't possibly save the metadata in the unknown version used in the file, so if you modify it at all you have to set the version to the current one.

Simply put: every time you overwrite the metadata, you must set the version to the one implemented by your metadata-writing code.