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

[Tom Lord]

    > From: Thomas Zander <address@hidden>

Am I confusing you with someone else or are you the list member who is
a human factors expert?

So on the one hand, I think this thread points to an incredibly
interesting, lucrative, challenging, winning, important, amazingly
cool area.   It deserves all kinds of attention:  "Revision Control
for Collaborative Documents."

On the other hand: we aren't even getting off the ground in the actual
content of the thread, getting bogged down in tired old nonesense
about how XML solves everything.

It (unsurprisingly) turns out that revision control for documents is a
serious and difficult topic which people have been exploring in
academic publications for quite some time.

Some quick googling suggests that you might want to start with:

  C. M. Neuwirth, R. Candhok, D. S. Kaufer, J. Morris and D. Miller
  (1992). Flexible Diff-ing in a Collaborative Writing
  System. CSCW'92 - Proceedings of the Conference on
  Computer-Supported Cooperative Work, . ACM Press. pp. 147-154.

  http://eserver.org/home/neuwirth/Publications/acm-pdfs/cscw92-p147.pdf

and, in fact, Neuwirth seems to be broadly interested and productive
in this general area and is probably also a good cite point for
literature searches:

     http://eserver.org/home/neuwirth/neuwirth.html

Even today, one could probably get a thesis (or more) out of working
on revision control for documents.  My opinion is that it would be
excellent fundamental research to get into -- it's solvable, probably
very valuable, quite hard, and widely multi-disciplinary.
Unfortunately, my hunch is that it is going to be tricky to retrofit
onto existing document processing tools.

I look forward to (more) papers such as:

  ~ Document Format Design Guidelines for Revision Control Features --
    Planning for Change Representation in Markup Languages
  ~ Human Factors Considerations for Interactively Guided Changeset Generation
  ~ Human Factors Considerations for Interactively Guided Changeset
    Application
  ~ The Logical Structure of Collaborative Writings -- A Programmer's
    View of Document Revision Control
  ~ Human Factors Considerations for Presenting Merge Results
  ~ Algorithms for Semantically Controlled Document Diffing and Patching
  ~ Social Considerations for Managing Revision Controlled Documents
  ~ Document-Oriented Revision Control System Interfaces
  ~ The Social Impact of Document Revision Control on Collaborative Workplaces
  ~ Managing Collaborative Workplaces with Document Revision Control
    -- A Study of Software Capability Requirements
  ~ Proofreading vs. Document Revision Control: Avoiding the
    Incoherent Paragraph Problem
  
and I'll be happy to write:

  ~ Implementing Distributed Document Revision Control Using Arch




    > On Monday 22 December 2003 16:51, Tom Lord wrote:
    >> I've no doubt that a proper XML-diff/patch will produce a
    >> syntactically valid XML file given syntactically valid XML inputs  --
    >> that is not the issue.

    >> The question is whether they will produce (a) valid and then (b) sane
    >> OO documents given valid and sane OO document inputs.

    > If not; then the Schema is needed to do so which will make sure
    > it is. But I doubt it will be needed.

I'm really puzzled, for multiple reasons, why you think that "Schema"
are in any way relevent here or that they solve any problem.  You're
just reinforcing my feeling that W3C productions have long since
degenerated into non-productive buzzword slingling and are largely to
blame for the stalling of the industry known as the burst of the .com
bubble (and worse problems).

OO bundles contain one or more XML files, each of which must be in a
language defined as a particular subset of XML.  Generic
XML-diff/patch tools are not guaranteed to produce output in that
subset of XML, even given inputs which are in that subset of XML.  As
asuffield has pointed out, it is implausible to believe that generic
XML-diff/patch tools will reliably produce valid, let alone useful
output in the appropriate XML-subset languages.  I think this is the
N+1th time someone has pointed this out in this thread.




    > Besides; the proposal was to make the merge-conflicts be handled
    > by OOo in a specific 'merge' widget that converts the DOM domain
    > objects to viewable changes so the user can select the revision
    > (A, B, A and B, B and A) that should be used in the resulting
    > document.

I have little idea what you might be talking about.  "widget"?  "DOM
domain objects"?  

This is like saying: "Mr. Ford!  Exciting News!  I have figured out
how we can mass-produce your model T.   It's quite simple, really:  we
need only build a machine whose gears and levers transform raw
materials into automobiles.   Gears and levers are well understood
technology so I am sure that your mechanics will have little
difficulty assembling this machine."


-t