.zip and .xml are too generic as extension names

[Martijn Faassen]

I believe that calling our save file formats .zip and .xml is a step in the
wrong direction.

Renaming Silva .slv to .xml decreases the utility of the extension. It is now
not possible for either a human or a computer to distinguish it from any
arbitrary .xml file. This makes it harder to search as a human, and harder to
attach software to it for a computer (like windows). Typically XML files in
particular formats have their own extensions, like .rdf and .xslt, and .html.
You can associate things like schemas with them for validation, and my editor
can actually recognize the extension and automatically load a RNG schema.

Similarly, naming the current rich export format .zip is way too generic.
Imagine doing a search for all silva exports on your system. You'll find *all*
zip files. It also becomes impossible to associate software with this extension.
Uploading a zip file into the XML import system in addition has no meaning for
Silva. OpenOffice also gives its save file format a different extension, and so
are Java .jar files called differently, even though they're both zip files.

While sometimes someone will want to unzip the file, or treat an slv file like
xml, a far more common operation used on these files would be using tools that
*specifically* target Silva exports; Silva itself is one such a tool.
Specifically using them as zip or xml files is advanced usage, and such advanced
users can be expected to be handle more particular extensions.

So let us stick with what gives us the most benefit and industry standard
practices concerning extension usage by software.

[Martijn Faassen (faassen)]

Nautilus/Gnome seems to recognize .slv files as XML files by default, see
attached screenshot.

[Martijn Faassen (faassen)]

The main hurdle for using our own extensions seems to be that Windows and Mac OS
do not recognize our extensions, unlike apparently Nautilus (which must be
sniffing the content to recognize it as XML).

Benefits of using .xml and .zip:

* less threatening than unassociated .slv for users; at least there is an
icon.

* something happens when you click on them; XML is opened in a browser and zip
file is opened in a zip extractor.

Benefits of using specific extensions:

* The ability for either users or software to associate tools with the
extensions that do something Silva-specific with these files, such as push them
to Docma. Powerusers who have specific XML editors will typically use a separate
extension to associate schema files with a specific format more easily.

* The ability to sort files by extension and easily distinguish these files from
other files.

* The ability to find all silva-related files using standard operating system
search techniques.

* User would be less prone to mistakes and accidentally upload a non-Silva xml
or zip file to Silva.

If Silva were a desktop application, the choice for separate extensions would be
clear, as we could make the tool-assocation and icon ourselves. Unfortunately
Silva is a web application.

One trick might be to write a simple installer that when run installs the
appropriate file associations for the silva file types on the operating system.
Users who work with .slv files a lot could then install this (it could be linked
to from the import/export screens in silva). Of course this would require
specific action by end users, and this set of users that won't do this might
exactly be those users most intimidated by non-icon associated files.

[Jan V Smith (jansmith)]

I noticed the difference in file extension names to earlier Silva's Import
Screens and wondered what had happened to .slv files. I further started
pondering on whether .xml in the import screen meant I could upload any .xml
file I have on my machine. I then started wondering about .zexp files and
decided they can only be imported in the zmi.

[Martijn Faassen (faassen)]

It definitely doesn't mean you can upload any XML file in your machine. While
Silva may not complain (which I consider actually a bug if it doesn't), it'll
definitely not do anything useful. The same story applies to the new zip files.

Jan, what are your thoughts about the .slv versus .xml and .newslv (we still
need to make up an extension if we're going this way) versus .zip for the Silva
import/export system? Any preferences?

[Martijn Faassen (faassen)]

I'm not going to give up on this discussion, as I still think the points in
favor of separate extensions are important, but I won't hold it for Silva 1.1 in
the name of expediency. I think the overly generic .zip and .xml extensions
right now give the wrong impression to end-users, and are not necessary to
support developers.

[Martijn Faassen (faassen)]

Another confusing issue in my mind is that zip file import is overloaded now in
the UI. It both is for asset importing *and* for full-media import. These are
very different operations, and you need to know what kind of zip file you have
to figure out what is actually going to happen. I think the UI should have two
separate parts, one for zip file import of assets, the other for full-media
import of full-media export files. Conflating the operations I think leads to
confusion.

Perhaps the import button should look more like the 'new' button in the UI with
a selection box, so you can get a special import dialog depending on what you
want to do: import full-media or import a zip file of assets. Each could present
its own import UI. Right now the import UI for full media is very confusion
as it offers two options which only apply to importing assets with zip files.
Once we get import options for full-media this will get even more confusing.

[Martijn Faassen (faassen)]

Another issue is that as soon as we want to add 1 single option for the
full-media import, we need to pull the forms apart anyway, otherwise it'll
really be hopelessly confusing. It'd be better if the forms were separate in the
first place.

[Sylvain Viollon (thefunny)]

This is not a problem.