"Uncompressed XML Files" format variants

[Friedrich W. H. Kossebau]

Am Montag, 12. November 2012, 15:19:01 schrieb Inge Wallin:
> On Monday, November 12, 2012 01:34:03 Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > I would propose to remove the option "Uncompressed XML Files" for non-
> > developer buils, or positively said, only enable it for developer builds.
> > Reasoning:
> > * only confuses the user ("what is the difference to compressed?")
> > * cannot be opened in other ODF programs
> > * results in data without a mimetype, so badly shown in
> > filemanagers/-dialogs * no/wrong thumbnails (for content.xml or directory)
> > 
> > Anyone objecting to this? If not, I will finish/prepare a patch and upload
> > for review which adds support for uncompressed/directory store formats
> > only in developer-like builds. Such a build I assume if NDEBUG is _not_
> > set. Or any better idea what the condition should be?
> 
> I am against it for Calligra Author. The reason being that it's a good
> format if you want to collaborate on a document and want to be able to
> follow the changes in a version control system.
> 
> The documentation team decided to use this format for the Author / Words
> documentation.

Then I urge you to reconsider your decision:

* "Uncompressed XML Files" is not defined by any OpenDocument spec, so calling 
it a "OpenDocument" format is wrong (and if I was in OASIS I would even think 
about pointing to my lawyer stick ;) ). Worse, it is slightly damaging the 
OpenDocument movement as this is an unofficial variant which is not defined 
anywhere (besides in code) and only supported by one implementation. Which is 
what we want to get free from, no?

* There is zero support for filesystem-directory-based documents: Documents 
saved that way have no mimetype (sadly, I whished directories could have), 
thus are not assigned to default handlers or can be shown with a proper icon. 
Also thumbnailing is not there. Do you really want to tell you users they have 
to deal with that non-comfort?

The argument with the VCS I see, but that is more theory at least ATM, no? 
Have you ever looked at a diff between a roundtrip? Currently e.g. all xml ids 
are regenerated on saving, spoiling a nice diff.
And the real issue here is that VCSs still seem to be only for textline-based 
sourcecode files, unable/willing to smartly deal with file-archives and tree-
based structures like XML/JSON.
Better find a VCS which does not do dump diffs on "binary" files but instead 
does deep-package diffs where possible.

Cheers
Friedrich