[Gnu-arch-users] Re: revision control for documents (was plug-in foo)

[michael josenhans]

Tom Lord wrote:
> How they did it in the stone age....  (a rant)
>
>
> Screw this GUI editor foo.   Not really screw it but -- don't try to
> hide, from _any_ user, the underlying markup language.  Users are
> expected to learn that they are editting these markup source programs
> (which they might have to edit directly) and programmers are expected
> to make that a pleasant task.
>
> Troff and tiny languages built on top of troff will do as a first
> approximation.
>
> Then add some coding conventions.   The ones beaten into my head as a
> youngster were things like:
>
>         Start every sentence on a new line.

Interesting.

There is no problem with pretty printing the XML file into any other 
equivalent format more readable than the current XML format.

One very anying thing when defining XML langauges still in the move, is 
the differents that attributes are not represnted as sub-nodes.

E.g.:

<blub>
        < bla bla_name='seven'>7</bla>
<blub>

Could be easily witten as:
<blub>
        <bla>
                <bla_name>seven</bla_name>
                7
        </bla>
<blub>

However this does not seem to work, as XML and DTD do not know the 
difference between ordered and unorderd nodes.

The DTD provides more options restrict the content and existence of 
attirbutes, than it does with element nodes. But why is there such a big 
difference?

> Why did this make sense?
>
> Well, for one thing, with "every sentence on a new line" -- plain old
> diff(1) and patch(1) do a _much_ better job.

XML is about keeping data struture seperated from representation format.

There is no reason why an XML tree can not be represented in any other 
equivalent more readble and human comparable format.

- Would it be beneficial to replace element tag nesting by indention?
- Would it be beneficial use a tree like format as python does?


Example:


blub
        bla
                bla_name:
                        7
                :
                seven
--End-of-File---

Thus the diff process would consist of the following steps.

1) Convert all XML files in an equvalent diff3-capable format
2) Diff3 all files, respolve conficts maually.
3) Save the merged file.
4) Validated tree structure against the DTD
5) Convert the merged file back to XML.

Optional we could ask XML-diff tools to resolve all conficts. And only 
it those tool claim to get merge conficts, use the procedure to resolve 
the rest.

> The cost, of course, was that every user had to be aware of, and
> somewhat had to learn, the underlying markup language.  For example,
> when patch produced invalid troff, they had to be able to fix that.
> They had to not go into mode that involved running around the room in
> circles, waving their arms to signal panic, when confronted with a
> line that said ".rj".

Agree. Have manual editing as fallback in place is a good thing.

I am not convinced that special purpose markup languages are better for 
users than XML. There are already today so many strange configuartion 
files with unclear file format discriptions.

> If you're presenting the truth to the user, then patch(1) and diff(3)
> output are quite reasonable things to present.

When you have understood the problems with manual merging, it is likely 
much simpler to create a good working GUI.


Michael
PS:
I have now to back-off for a while ..