"Uncompressed XML Files" format variants

[Jos van den Oever]

On 11/12/2012 05:10 PM, Inge Wallin wrote:
> 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.
>
>> 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.
>
>> 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? ;)
>
> 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.
>
> 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.

One could use git hooks that normalize the fodt before committing and 
check on the server side that all fodt that is being committed conforms 
to the normalization. That is some work initially but would make quite 
some people happy.

However, i think xml:id would fall outside of the normalization and in 
fact an ODF editor should not change the xml:id unless the element on 
which it occurs is copied or split at which point it is not clear 
anymore which of the two new elements should receive the xml:id.

Cheers,
Jos