"Uncompressed XML Files" format variants

[Friedrich W. H. Kossebau]

Am Montag, 12. November 2012, 17:10:09 schrieb Inge Wallin:
> On Monday, November 12, 2012 16:01:20 Friedrich W. H. Kossebau wrote:
> > 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:
> Together with Jos description of fodt, I can actually consider to
> reconsider.
> :)

:)

> > * "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?
> 
> This is true.
> 
> > * 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?
> 
> Not sure what you mean by "zero support" here though. I can de facto both
> save and load documents just fine. If you mean "in the OS" then I can
> agree.

Yes, "in the OS" :)

> > The argument with the VCS I see, but that is more theory at least ATM, no?
> 
> No, not at all.  However it seems that the same issue can be solved by using
> fodt as Jos described even though the lack of RDF can become a problem in
> the future. I'd really like to see a solution to that.
> 
> > 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.
> 
> The xml id regeneration does spoil the diffs. But I think that Calligra
> formats the XML nicely enough that a line based VCS is still usable. And I
> also don't think that it will make the diffs unreadable and hide the real
> content changes.

In the long run we need to make sure the xml ids are consistent anyway (like 
Jos said), so that was just an argument for now.
Though looking at diffs on the text-file level is not what we should optimize 
for, or? Still nice to have, I agree, if only for as-small-diffs-as-possible.

> > Better find a VCS which does not do dump diffs on "binary" files but
> > instead does deep-package diffs where possible.
> 
> Now, *this* is really more theory than practice.  Suppose I found such a
> VCS, would you lobby that KDE changes to it? ;)

Sure ;) Well, for KDE stuff I hope one day somebody will extend git in that 
direction.

> But all this said, I don't think we'll use uncompressed odf. It seems the
> drawbacks of fodt are not as large as I thought.

Okay, looking forward to hear that such a change will work for you without any 
real disadvantages :)

> Would you go for disable saving and still allow loading? That way you won't
> destroy for those few that actually have uncompressed odf files out there.

Hm, what about a small script instead which transforms the uncompressed files 
into a fod* or od* instead? Because there might be only a few people out there 
with such files. But having support visible (and some codesize) in the program 
for everybody out there, would that be worth it?
Perhaps for a transition period (until 3.0), okay. But in the long run I would 
vote for making it a completely developer-only option.
So after loading such a document from uncompressed xml files it should be 
turned into one without an origin, so on activating the "Save" action it will 
be handled as a new one created from a template, okay with this behaviour?

Cheers
Friedrich