[Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?

[michael josenhans]

Thomas Zander wrote:

> In KOffice and on OpenOffice there have been on-and-off discussions on 
> saving the file to a filesystem layer like 'cvs://'.
> This touches the same idea, and sidesteppes some problems your solution 
> will face.

My idea would be to make tools like OO patchset-aware. The current way 
of change tracking does not work according my understanding very well.

This is not an OO-problem, but rather a revision mangement problems all 
office suites face that I know.

> Since OOo will save some 5 different XML streams inside a zip file its 
> quite easy to do revision management on XML only streams once you have a 
> XMLDiff application in place. (which should be first priority)

It is actually my motiavtion. Even an OO-change tracking mode could be 
implemented starting the initial files. When changes are added, patches 
could be stored as patchsets by OO in the OO-zip file container 
invisible to the user, maybe in a different revision history directory.

This would enable revison tracking for the sake of loading speed and 
eventually branching for the sake of loading / saving speed.

When change tracking is disabled, all patchset could be merged 
immediately when saving.

> The hard part is walking through the history at that point; which will 
> probably be a OOo only GUI. 

I think diff3 is only one representation for patches. Depending of the 
information content, other reprentation formats might be more 
appropriate. In OO-case one useful option would be a change tracking mode.

> Simply because they need to what the changes
> mean on screen. That part will be done in the office suites and can be 
> done with the current tla interface.

I would not like to merge a spreadsheet table with a diff tool, which 
does not know what a cell, a color or a formula is. Only geeks would 
like to that.

> I don't think this will work the way you think; the logic is in the wrong 
> place if you put it in a tla plugin. The logic should be inside OOo to 
> match changes there, and to be able to resolve problems based on 
> intelligence that only OOo can have.

> Think about specific problems you have to solve in this program only to 
> find out you don't have the data-structures to do it.
> Notice that a DTD can change and you have to chose based on the file being 
> offered to you.

I agree here. But first we should understand patching of XML files and 
their limitations.

Example:

When you make a word in the OO-writer bold and another word underline. 
The OO-filer seens to create 2 new styles nodes with the attributes 'T1' 
and 'T2' in the file 'content.xml':

<style:style style:name="T1" style:family="text">
        <style:properties fo:color="#800000"fo:font-weight="bold"/>
</style:style>

<style:style style:name="T2" style:family="text">
        <style:properties fo:color="#800000"       
        style:text-underline="single"
        style:text-underline-color="font-color"/>
</style:style>

and addes the tags to the text:

<text:p text:style-name="Standard">This is a very very short text 		 
<text:span text:style-name="T1">written</text:span> with open
        <text:span text:style-name="T2">office</text:span>.
</text:p>

Using tags as enumerations like 'T1', 'T2', etc. Is very branch 
unfriendly. An arch like solution would likely be, if tags contain the 
branch name. Like: 'Branch_1:T1', 'Branch_1:T2' or 'Branch_2:T2'.

> There is work going on on the XML streams formats which OOo (and probably 
> other office suites) are going to use in the near future. Last time I 
> participated in those discussions there were hooks in place to allow this 
> kind of functionality specifically (in the file-format).
>
> I think you should talk to them before you do anything.
>
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office

Thanks for the link.

As a first goal I would see, making arch xml aware and eventually able 
to work with zipped directories.

Michael