Collaboratively Editing a TEI XML Document?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Collaboratively Editing a TEI XML Document?

Ruchira Datta
Dear all,

I am pretty new to TEI, and also to the Oxygen XML Editor.  If we use Track Changes to collaboratively edit an XML document in Oxygen, is there a way to smoothly edit it simultaneously as one does with Google Docs, or does one have to pass the document back and forth and/or manually integrate tracked changes from multiple documents, as one does with Microsoft Word documents?  Can we keep it so that two people editing the same document on different computers each see the other's changes as well as their own as tracked changes highlighted in the same document?


Thank you in advance for your help!
—Ruchira S. Datta
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

C. M. Sperberg-McQueen
> On Oct 25, 2017, at 10:15 AM, Ruchira Datta <[hidden email]> wrote:
>
> Dear all,
>
> I am pretty new to TEI, and also to the Oxygen XML Editor.  If we use Track Changes to collaboratively edit an XML document in Oxygen, is there a way to smoothly edit it simultaneously as one does with Google Docs, or does one have to pass the document back and forth and/or manually integrate tracked changes from multiple documents, as one does with Microsoft Word documents?  Can we keep it so that two people editing the same document on different computers each see the other's changes as well as their own as tracked changes highlighted in the same document?

Not a direct answer to the question you asked (which requires more
knowledge of Oxygen than I have), but for what it’s worth ...

A relatively straightforward approach to collaborative authorship in XML
is to have a master copy of the document in a repository managed by
some version-control system, either a distributed version-control system
like git or Hg (Mercurial) or a non-distributed one like Subversion.  

These occupy a sort fo middle ground between the two possibilities you
describe.  They don’t require hand work to integrate changes, so they are
less work than what you describe for Word.  They don’t involve an omniscient
central server, so if two people are editing the document at the same time,
they won’t see each other’s changes until they synchronize their work,
unlike the situation with Google Docs.

The main drawback I’m aware of is that some people (and so possibly
some of one’s likely collaborators) will need to learn to use the
version-control system, which can be tedious for tham and for those
they are collaborating with.  And some people find the model of standard
version-control systems counter-intuitive and very difficult to
internalize.


********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Gioele Barabucci-2
On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
> The main drawback I’m aware of is that some people (and so possibly
> some of one’s likely collaborators) will need to learn to use the
> version-control system, which can be tedious for tham and for those
> they are collaborating with.  And some people find the model of standard
> version-control systems counter-intuitive and very difficult to
> internalize.

Allow me to stress one particular point: What is most difficult to grasp
is the fact that

* there will be _conflicts_ at "merge time";
* every synchronization made by any collaborator is an opportunity for
conflicts;
* conflicts can be resolved only by those that have a deep knowledge of
the inner mechanisms of the used version control system.

For example, hand editing XML files + git will often lead to much
head-scratching and utterances such as "this whole thing does not work,
what a waste of time".

The only way to use version control system with XML files is to have a
rigid workflow that minimize said conflicts (tiny changes, frequent
synchronizations, well defined work areas, only few command allowed,
etc). Parts of this workflow can be automated, but meticulousness from
all the collaborator is also required, as well as a bit of studying.

Handling conflicts is what makes version control system much more
complicated than a Google Doc. However the investment in using VCSes
often pays off in many projects.

Regards,

--
Gioele Barabucci <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Martin Mueller
Echoing Gioele’s comment, it is with collaboration as with other things in life. You preach water but drink wine.

I don’t know what it is you’re editing, but I would be inclined to chunk the XML source into bits that can be re-assembled and insist that only one person edits one part at a time and there is one person who is in charge of keeping the bits assembled in the proper order.

On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Gioele Barabucci" <[hidden email] on behalf of [hidden email]> wrote:

    On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
    > The main drawback I’m aware of is that some people (and so possibly
    > some of one’s likely collaborators) will need to learn to use the
    > version-control system, which can be tedious for tham and for those
    > they are collaborating with.  And some people find the model of standard
    > version-control systems counter-intuitive and very difficult to
    > internalize.
   
    Allow me to stress one particular point: What is most difficult to grasp
    is the fact that
   
    * there will be _conflicts_ at "merge time";
    * every synchronization made by any collaborator is an opportunity for
    conflicts;
    * conflicts can be resolved only by those that have a deep knowledge of
    the inner mechanisms of the used version control system.
   
    For example, hand editing XML files + git will often lead to much
    head-scratching and utterances such as "this whole thing does not work,
    what a waste of time".
   
    The only way to use version control system with XML files is to have a
    rigid workflow that minimize said conflicts (tiny changes, frequent
    synchronizations, well defined work areas, only few command allowed,
    etc). Parts of this workflow can be automated, but meticulousness from
    all the collaborator is also required, as well as a bit of studying.
   
    Handling conflicts is what makes version control system much more
    complicated than a Google Doc. However the investment in using VCSes
    often pays off in many projects.
   
    Regards,
   
    --
    Gioele Barabucci <[hidden email]>
   

Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Radu Coravu
Hi all,

Besides the Oxygen standalone product we also have an Oxygen Web Author
(an online XML editing tool):

https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html

The Web Author allows you to edit TEI documents from a variety of
storage facilities, it does not yet have a simultaneous editing facility
but we are considering adding such a feature.

In the end the final implemented feature will possibly be limited, we
might allow for example people to make only comments on the content. Or
if we allow full concurrent editing, at a certain time only one person
will be able to edit inside a particular paragraph.

Regards,

Radu


On 10/25/17 8:23 PM, Martin Mueller wrote:

> Echoing Gioele’s comment, it is with collaboration as with other things in life. You preach water but drink wine.
>
> I don’t know what it is you’re editing, but I would be inclined to chunk the XML source into bits that can be re-assembled and insist that only one person edits one part at a time and there is one person who is in charge of keeping the bits assembled in the proper order.
>
> On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Gioele Barabucci" <[hidden email] on behalf of [hidden email]> wrote:
>
>      On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>      > The main drawback I’m aware of is that some people (and so possibly
>      > some of one’s likely collaborators) will need to learn to use the
>      > version-control system, which can be tedious for tham and for those
>      > they are collaborating with.  And some people find the model of standard
>      > version-control systems counter-intuitive and very difficult to
>      > internalize.
>      
>      Allow me to stress one particular point: What is most difficult to grasp
>      is the fact that
>      
>      * there will be _conflicts_ at "merge time";
>      * every synchronization made by any collaborator is an opportunity for
>      conflicts;
>      * conflicts can be resolved only by those that have a deep knowledge of
>      the inner mechanisms of the used version control system.
>      
>      For example, hand editing XML files + git will often lead to much
>      head-scratching and utterances such as "this whole thing does not work,
>      what a waste of time".
>      
>      The only way to use version control system with XML files is to have a
>      rigid workflow that minimize said conflicts (tiny changes, frequent
>      synchronizations, well defined work areas, only few command allowed,
>      etc). Parts of this workflow can be automated, but meticulousness from
>      all the collaborator is also required, as well as a bit of studying.
>      
>      Handling conflicts is what makes version control system much more
>      complicated than a Google Doc. However the investment in using VCSes
>      often pays off in many projects.
>      
>      Regards,
>      
>      --
>      Gioele Barabucci <[hidden email]>
>      
>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

David Farmer

Apologies if my question is laughably ignorant,
but why can't there be something like Google Docs with
simultaneous editing and you can see each others cursor,
but what you are editing is XML, with automatic indentation
and tag completion?

In particular, why would it matter if two people are editing the
same paragraph?

Regards,

David


On Wed, 25 Oct 2017, Radu Coravu wrote:

> Hi all,
>
> Besides the Oxygen standalone product we also have an Oxygen Web Author (an
> online XML editing tool):
>
> https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html
>
> The Web Author allows you to edit TEI documents from a variety of storage
> facilities, it does not yet have a simultaneous editing facility but we are
> considering adding such a feature.
>
> In the end the final implemented feature will possibly be limited, we might
> allow for example people to make only comments on the content. Or if we allow
> full concurrent editing, at a certain time only one person will be able to
> edit inside a particular paragraph.
>
> Regards,
>
> Radu
>
>
> On 10/25/17 8:23 PM, Martin Mueller wrote:
>>  Echoing Gioele’s comment, it is with collaboration as with other things in
>>  life. You preach water but drink wine.
>>
>>  I don’t know what it is you’re editing, but I would be inclined to chunk
>>  the XML source into bits that can be re-assembled and insist that only one
>>  person edits one part at a time and there is one person who is in charge
>>  of keeping the bits assembled in the proper order.
>>
>>  On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion
>>  list on behalf of Gioele Barabucci" <[hidden email] on behalf of
>>  [hidden email]> wrote:
>>
>>       On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>> >  The main drawback I’m aware of is that some people (and so possibly
>> >  some of one’s likely collaborators) will need to learn to use the
>> >  version-control system, which can be tedious for tham and for those
>> >  they are collaborating with.  And some people find the model of standard
>> >  version-control systems counter-intuitive and very difficult to
>> >  internalize.
>>
>>       Allow me to stress one particular point: What is most difficult to
>>       grasp
>>       is the fact that
>>
>>       * there will be _conflicts_ at "merge time";
>>       * every synchronization made by any collaborator is an opportunity
>>       for
>>       conflicts;
>>       * conflicts can be resolved only by those that have a deep knowledge
>>       of
>>       the inner mechanisms of the used version control system.
>>
>>       For example, hand editing XML files + git will often lead to much
>>       head-scratching and utterances such as "this whole thing does not
>>       work,
>>       what a waste of time".
>>
>>       The only way to use version control system with XML files is to have
>>       a
>>       rigid workflow that minimize said conflicts (tiny changes, frequent
>>       synchronizations, well defined work areas, only few command allowed,
>>       etc). Parts of this workflow can be automated, but meticulousness
>>       from
>>       all the collaborator is also required, as well as a bit of studying.
>>
>>       Handling conflicts is what makes version control system much more
>>       complicated than a Google Doc. However the investment in using VCSes
>>       often pays off in many projects.
>>
>>       Regards,
>>
>>       --
>>       Gioele Barabucci <[hidden email]>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Ruchira Datta
In reply to this post by Martin Mueller
Thank you all for your helpful replies!

Indeed, my first job as a professional programmer was thirty years ago, and i personally like and use the git VCS.  I've been using it for my personal contributions in the solo phase of this two-person project.

However, as far as highlighting specific changes, this approach generally uses diff, which is line-oriented.  I've been finding that Oxygen reflows the lines in the XML document (for instance, when switching between text and author mode, or when a word is added) in ways that i cannot predict or control.  This results in many lines being “changed” when it's really just a change to the whitespace.  There are so many of these whitespace changes that trying to find the actual change is like trying to find a needle in a haystack.  I tried using the Oxygen “Compare Files” option, however this seems to be basically the same as diff and didn't help.  Large numbers of lines are highlighted as changed, where the only change is actually due to spacing and indentation.

I've been muddling along with this, and i tried adding the repository to bitbucket and installing git on my collaborator's computer yesterday.  My collaborator is not the most tech-savvy person (even editing TEI XML files in Oxygen author mode is a bit of a struggle).  Looking at the side-by-side diff might have been okay, except this whitespace issue makes it very hard to use.

By the way, we found Dropbox also produces conflicted versions when two people edit the same Microsoft Word file at the same time (a bit like a VCS does).  I was personally impressed that it does this, however we don't find it practical.

When two people edit a Google Doc simultaneously, Google Docs keeps the revision history, with a view that highlights changes, and it's possible to see who did what.  (However, it doesn't have Oxygen's author mode for viewing a TEI XML file, or any validation, etc.)

My collaborator is used to using Track Changes in Word, so we were happy to find that Oxygen also has Track Changes.  Then it seems from the discussion so far, that the best option may be to keep the files subdivided and have one person acting as the master of each file at any given time, as Martin suggests.  (I was hoping to hear from you, Martin, as i had seen your reports about working on collaborative curation in the mailing list archives and thought you would probably have worked out the most practicable current solution.)

Thank you all again for your help!  Will be happy to hear anyone else chiming in…

—Ruchira

On Wed, Oct 25, 2017 at 11:23 AM, Martin Mueller <[hidden email]> wrote:
Echoing Gioele’s comment, it is with collaboration as with other things in life. You preach water but drink wine.

I don’t know what it is you’re editing, but I would be inclined to chunk the XML source into bits that can be re-assembled and insist that only one person edits one part at a time and there is one person who is in charge of keeping the bits assembled in the proper order.

On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Gioele Barabucci" <[hidden email] on behalf of [hidden email]> wrote:

    On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
    > The main drawback I’m aware of is that some people (and so possibly
    > some of one’s likely collaborators) will need to learn to use the
    > version-control system, which can be tedious for tham and for those
    > they are collaborating with.  And some people find the model of standard
    > version-control systems counter-intuitive and very difficult to
    > internalize.

    Allow me to stress one particular point: What is most difficult to grasp
    is the fact that

    * there will be _conflicts_ at "merge time";
    * every synchronization made by any collaborator is an opportunity for
    conflicts;
    * conflicts can be resolved only by those that have a deep knowledge of
    the inner mechanisms of the used version control system.

    For example, hand editing XML files + git will often lead to much
    head-scratching and utterances such as "this whole thing does not work,
    what a waste of time".

    The only way to use version control system with XML files is to have a
    rigid workflow that minimize said conflicts (tiny changes, frequent
    synchronizations, well defined work areas, only few command allowed,
    etc). Parts of this workflow can be automated, but meticulousness from
    all the collaborator is also required, as well as a bit of studying.

    Handling conflicts is what makes version control system much more
    complicated than a Google Doc. However the investment in using VCSes
    often pays off in many projects.

    Regards,

    --
    Gioele Barabucci <[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Radu Coravu
In reply to this post by David Farmer
Hi David,

I have not looked much into this as I will not be the one implementing it.

The main problem I see are network delays and latency. For example if I
start typing inside a paragraph, my changes need to be propagated
instantly to everybody else but because of network latency that
propagation of changes is not done instantly so at the same time
somebody else may be doing some action which conflicts with mine, for
example they might be deleting the entire paragraph. So would the
paragraph they deleted contain also the changes that I just inserted or
would it be considered that they removed the old paragraph contents,
before my changes were inserted... Of course with enough time and effort
such things could probably be handled in some way.

Somehow if when moving the cursor inside one paragraph, that paragraph
would be locked by you, this entire complication could be avoided.

I think that Google Spreadsheets does a similar thing, once you start
editing a table cell, that cell is fully yours and is locked to others,
but I might be wrong...

Regards,

Radu


On 10/25/17 9:14 PM, David Farmer wrote:

>
> Apologies if my question is laughably ignorant,
> but why can't there be something like Google Docs with
> simultaneous editing and you can see each others cursor,
> but what you are editing is XML, with automatic indentation
> and tag completion?
>
> In particular, why would it matter if two people are editing the
> same paragraph?
>
> Regards,
>
> David
>
>
> On Wed, 25 Oct 2017, Radu Coravu wrote:
>
>> Hi all,
>>
>> Besides the Oxygen standalone product we also have an Oxygen Web
>> Author (an online XML editing tool):
>>
>> https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html
>>
>> The Web Author allows you to edit TEI documents from a variety of
>> storage facilities, it does not yet have a simultaneous editing
>> facility but we are considering adding such a feature.
>>
>> In the end the final implemented feature will possibly be limited, we
>> might allow for example people to make only comments on the content.
>> Or if we allow full concurrent editing, at a certain time only one
>> person will be able to edit inside a particular paragraph.
>>
>> Regards,
>>
>> Radu
>>
>>
>> On 10/25/17 8:23 PM, Martin Mueller wrote:
>>>  Echoing Gioele’s comment, it is with collaboration as with other
>>> things in
>>>  life. You preach water but drink wine.
>>>
>>>  I don’t know what it is you’re editing, but I would be inclined to
>>> chunk
>>>  the XML source into bits that can be re-assembled and insist that
>>> only one
>>>  person edits one part at a time and there is one person who is in
>>> charge
>>>  of keeping the bits assembled in the proper order.
>>>
>>>  On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public
>>> discussion
>>>  list on behalf of Gioele Barabucci" <[hidden email] on
>>> behalf of
>>>  [hidden email]> wrote:
>>>
>>>       On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>>> >  The main drawback I’m aware of is that some people (and so possibly
>>> >  some of one’s likely collaborators) will need to learn to use the
>>> >  version-control system, which can be tedious for tham and for those
>>> >  they are collaborating with.  And some people find the model of
>>> standard
>>> >  version-control systems counter-intuitive and very difficult to
>>> >  internalize.
>>>
>>>       Allow me to stress one particular point: What is most
>>> difficult to
>>>       grasp
>>>       is the fact that
>>>
>>>       * there will be _conflicts_ at "merge time";
>>>       * every synchronization made by any collaborator is an
>>> opportunity
>>>       for
>>>       conflicts;
>>>       * conflicts can be resolved only by those that have a deep
>>> knowledge
>>>       of
>>>       the inner mechanisms of the used version control system.
>>>
>>>       For example, hand editing XML files + git will often lead to much
>>>       head-scratching and utterances such as "this whole thing does not
>>>       work,
>>>       what a waste of time".
>>>
>>>       The only way to use version control system with XML files is
>>> to have
>>>       a
>>>       rigid workflow that minimize said conflicts (tiny changes,
>>> frequent
>>>       synchronizations, well defined work areas, only few command
>>> allowed,
>>>       etc). Parts of this workflow can be automated, but meticulousness
>>>       from
>>>       all the collaborator is also required, as well as a bit of
>>> studying.
>>>
>>>       Handling conflicts is what makes version control system much more
>>>       complicated than a Google Doc. However the investment in using
>>> VCSes
>>>       often pays off in many projects.
>>>
>>>       Regards,
>>>
>>>       --
>>>       Gioele Barabucci <[hidden email]>
>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Radu Coravu
In reply to this post by Ruchira Datta

Hi Ruchira,

About the whitespace handling Oxygen does when changing between the Author and Text pages, with newer versions of Oxygen (I think that starting with 18.1), in the Oxygen Preferences->"Editor / Edit Modes / Author" page there is a "Compatibility with other tools" setting which you could try to set to "Break lines only after elements displayed as blocks, do not indent".

Also Oxygen 19.1 added visual files comparison, so you can open two TEI documents side by side and switch the visualization to the Author editing mode instead of seeing the XML content.

Regards,

Radu


On 10/25/17 9:26 PM, Ruchira Datta wrote:
Thank you all for your helpful replies!

Indeed, my first job as a professional programmer was thirty years ago, and i personally like and use the git VCS.  I've been using it for my personal contributions in the solo phase of this two-person project.

However, as far as highlighting specific changes, this approach generally uses diff, which is line-oriented.  I've been finding that Oxygen reflows the lines in the XML document (for instance, when switching between text and author mode, or when a word is added) in ways that i cannot predict or control.  This results in many lines being “changed” when it's really just a change to the whitespace.  There are so many of these whitespace changes that trying to find the actual change is like trying to find a needle in a haystack.  I tried using the Oxygen “Compare Files” option, however this seems to be basically the same as diff and didn't help.  Large numbers of lines are highlighted as changed, where the only change is actually due to spacing and indentation.

I've been muddling along with this, and i tried adding the repository to bitbucket and installing git on my collaborator's computer yesterday.  My collaborator is not the most tech-savvy person (even editing TEI XML files in Oxygen author mode is a bit of a struggle).  Looking at the side-by-side diff might have been okay, except this whitespace issue makes it very hard to use.

By the way, we found Dropbox also produces conflicted versions when two people edit the same Microsoft Word file at the same time (a bit like a VCS does).  I was personally impressed that it does this, however we don't find it practical.

When two people edit a Google Doc simultaneously, Google Docs keeps the revision history, with a view that highlights changes, and it's possible to see who did what.  (However, it doesn't have Oxygen's author mode for viewing a TEI XML file, or any validation, etc.)

My collaborator is used to using Track Changes in Word, so we were happy to find that Oxygen also has Track Changes.  Then it seems from the discussion so far, that the best option may be to keep the files subdivided and have one person acting as the master of each file at any given time, as Martin suggests.  (I was hoping to hear from you, Martin, as i had seen your reports about working on collaborative curation in the mailing list archives and thought you would probably have worked out the most practicable current solution.)

Thank you all again for your help!  Will be happy to hear anyone else chiming in…

—Ruchira

On Wed, Oct 25, 2017 at 11:23 AM, Martin Mueller <[hidden email]> wrote:
Echoing Gioele’s comment, it is with collaboration as with other things in life. You preach water but drink wine.

I don’t know what it is you’re editing, but I would be inclined to chunk the XML source into bits that can be re-assembled and insist that only one person edits one part at a time and there is one person who is in charge of keeping the bits assembled in the proper order.

On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion list on behalf of Gioele Barabucci" <[hidden email] on behalf of [hidden email]> wrote:

    On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
    > The main drawback I’m aware of is that some people (and so possibly
    > some of one’s likely collaborators) will need to learn to use the
    > version-control system, which can be tedious for tham and for those
    > they are collaborating with.  And some people find the model of standard
    > version-control systems counter-intuitive and very difficult to
    > internalize.

    Allow me to stress one particular point: What is most difficult to grasp
    is the fact that

    * there will be _conflicts_ at "merge time";
    * every synchronization made by any collaborator is an opportunity for
    conflicts;
    * conflicts can be resolved only by those that have a deep knowledge of
    the inner mechanisms of the used version control system.

    For example, hand editing XML files + git will often lead to much
    head-scratching and utterances such as "this whole thing does not work,
    what a waste of time".

    The only way to use version control system with XML files is to have a
    rigid workflow that minimize said conflicts (tiny changes, frequent
    synchronizations, well defined work areas, only few command allowed,
    etc). Parts of this workflow can be automated, but meticulousness from
    all the collaborator is also required, as well as a bit of studying.

    Handling conflicts is what makes version control system much more
    complicated than a Google Doc. However the investment in using VCSes
    often pays off in many projects.

    Regards,

    --
    Gioele Barabucci <[hidden email]>




Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Ruchira Datta
In reply to this post by Radu Coravu


On Wed, Oct 25, 2017 at 12:29 PM, Radu Coravu <[hidden email]> wrote:
Hi David,

I have not looked much into this as I will not be the one implementing it.

The main problem I see are network delays and latency. For example if I start typing inside a paragraph, my changes need to be propagated instantly to everybody else but because of network latency that propagation of changes is not done instantly so at the same time somebody else may be doing some action which conflicts with mine, for example they might be deleting the entire paragraph. So would the paragraph they deleted contain also the changes that I just inserted or would it be considered that they removed the old paragraph contents, before my changes were inserted... Of course with enough time and effort such things could probably be handled in some way.

When my collaborator and i purposely tried doing this yesterday with Google Docs, one of us would “win” (whoever typed last), and the Google Doc would indicate who was the origin of the change.  As we could see each other's cursors, however, it would be easy for us to avoid doing this accidentally.  So essentially, either with Google Docs or this possible future feature, we would be implementing Martin's recommendation at the paragraph level rather than the file level.

Somehow if when moving the cursor inside one paragraph, that paragraph would be locked by you, this entire complication could be avoided.

I think that Google Spreadsheets does a similar thing, once you start editing a table cell, that cell is fully yours and is locked to others, but I might be wrong...

Regards,

Radu



On 10/25/17 9:14 PM, David Farmer wrote:

Apologies if my question is laughably ignorant,
but why can't there be something like Google Docs with
simultaneous editing and you can see each others cursor,
but what you are editing is XML, with automatic indentation
and tag completion?

In particular, why would it matter if two people are editing the
same paragraph?

Regards,

David


On Wed, 25 Oct 2017, Radu Coravu wrote:

Hi all,

Besides the Oxygen standalone product we also have an Oxygen Web Author (an online XML editing tool):

https://www.oxygenxml.com/webapp-demo-aws/app/oxygen.html

The Web Author allows you to edit TEI documents from a variety of storage facilities, it does not yet have a simultaneous editing facility but we are considering adding such a feature.

In the end the final implemented feature will possibly be limited, we might allow for example people to make only comments on the content. Or if we allow full concurrent editing, at a certain time only one person will be able to edit inside a particular paragraph.

My collaborator and i noticed this yesterday.  However, as we are both penniless educators, the cost is prohibitive.  So we didn't continue looking into it to see if it would do what we want.  

Thank you for your help,
—Ruchira

Regards,

Radu


On 10/25/17 8:23 PM, Martin Mueller wrote:
 Echoing Gioele’s comment, it is with collaboration as with other things in
 life. You preach water but drink wine.

 I don’t know what it is you’re editing, but I would be inclined to chunk
 the XML source into bits that can be re-assembled and insist that only one
 person edits one part at a time and there is one person who is in charge
 of keeping the bits assembled in the proper order.

 On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public discussion
 list on behalf of Gioele Barabucci" <[hidden email] on behalf of
 [hidden email]> wrote:

      On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>  The main drawback I’m aware of is that some people (and so possibly
>  some of one’s likely collaborators) will need to learn to use the
>  version-control system, which can be tedious for tham and for those
>  they are collaborating with.  And some people find the model of standard
>  version-control systems counter-intuitive and very difficult to
>  internalize.

      Allow me to stress one particular point: What is most difficult to
      grasp
      is the fact that

      * there will be _conflicts_ at "merge time";
      * every synchronization made by any collaborator is an opportunity
      for
      conflicts;
      * conflicts can be resolved only by those that have a deep knowledge
      of
      the inner mechanisms of the used version control system.

      For example, hand editing XML files + git will often lead to much
      head-scratching and utterances such as "this whole thing does not
      work,
      what a waste of time".

      The only way to use version control system with XML files is to have
      a
      rigid workflow that minimize said conflicts (tiny changes, frequent
      synchronizations, well defined work areas, only few command allowed,
      etc). Parts of this workflow can be automated, but meticulousness
      from
      all the collaborator is also required, as well as a bit of studying.

      Handling conflicts is what makes version control system much more
      complicated than a Google Doc. However the investment in using VCSes
      often pays off in many projects.

      Regards,

      --
      Gioele Barabucci <[hidden email]>




Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Craig A. Berry-3
In reply to this post by Ruchira Datta


On Oct 25, 2017, at 12:48 PM, Gioele Barabucci <[hidden email]> wrote:

Allow me to stress one particular point: What is most difficult to grasp
is the fact that

* there will be _conflicts_ at "merge time";
* every synchronization made by any collaborator is an opportunity for
conflicts;
* conflicts can be resolved only by those that have a deep knowledge of
the inner mechanisms of the used version control system.

For example, hand editing XML files + git will often lead to much
head-scratching and utterances such as "this whole thing does not work,
what a waste of time".

The only way to use version control system with XML files is to have a
rigid workflow that minimize said conflicts (tiny changes, frequent
synchronizations, well defined work areas, only few command allowed,
etc). Parts of this workflow can be automated, but meticulousness from
all the collaborator is also required, as well as a bit of studying.

Handling conflicts is what makes version control system much more
complicated than a Google Doc. However the investment in using VCSes
often pays off in many projects.

Indeed.  Versioning XML documents is tricky business. You have to have complete control of line breaks, indenting, and attribute ordering.  I have been using xmllint like so to indent a file to have a single-space indent:

$ cat format.sh
#!/bin/sh
tmp
="$(mktemp)"
XMLLINT_INDENT
=$' ' xmllint --encode UTF-8 --format "$1" --output "$tmp" 2>/dev/null || {
  echo
'fatal: `xmllint --format` failed for:' "$1" >&2
 
exit 1
}
mv
"$tmp" "$1"

and putting some version of that in a git pre-commit hook, so as far as the changes that git sees, differences only in non-significant whitespace should be eliminated.  However, I had a case recently where two lines in a file changed but it looked to git as though 45,000 had changed because the two lines were <div></div> with a huge chunk of text in between that ended up indented one level deeper than before.  So a  more robust solution would eliminate indents entirely, but that's not very reader-friendly.

Then there is the matter of attribute order.  I have seen tools and scripts that change the order of attributes for no particular reason, and of course an XML parser doesn't care, but to a VCS that shows up as a changed line, and once you have hundreds or thousands of lines where nothing really changed from an XML perspective, then you've pretty much lost the value of using version control and greatly increased the chances of conflicts with other users' changes.  You also risk more easily blowing the 1GB limit on free repositories on BitBucket or GitHub because all of those insignificant changes take up space.  So I'm contemplating adding a stylesheet that sorts attributes to my pre-commit hook.

This is a problem I thought I had solved but I keep finding cases where I hadn't, so it wouldn't surprise me if there are other gotchas I haven't encountered yet.


Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

C. M. Sperberg-McQueen
In reply to this post by Gioele Barabucci-2
> On Oct 25, 2017, at 11:47 AM, Gioele Barabucci <[hidden email]> wrote:
>
> On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>> The main drawback I’m aware of is that some people (and so possibly
>> some of one’s likely collaborators) will need to learn to use the
>> version-control system, which can be tedious for tham and for those
>> they are collaborating with.  And some people find the model of standard
>> version-control systems counter-intuitive and very difficult to
>> internalize.
>
> Allow me to stress one particular point: What is most difficult to grasp is the fact that
>
> * there will be _conflicts_ at "merge time";
> * every synchronization made by any collaborator is an opportunity for conflicts;
> * conflicts can be resolved only by those that have a deep knowledge of the inner mechanisms of the used version control system.

For the record - I agree that conflicts can be a pain (more of a pain
for CVS than for Subversion, more for Subversion than for git, in
my experience), but my experience with shared editing of SGML and
XML has not been anything like as dire as that pictured in this
response of Gioele or the various responses of others.   I am worried
that anyone who finds this thread in future will conclude that using
cvs or svn or git on XML documents is way too painful to be worth while.
That has not been my experience.
 
I admit that for a while, collaborators whose editors reflowed the text
caused a fair bit of heartburn in one project because the reflowing made
it hard to see what they had changed and what they had left unchanged,
but once those who cared had acquired and learned to use pcl-cvs and
ediff, reflowing was not an issue.

If variations in XML format ever became an issue in a project I was
involved in, I’d look for XML normalizers and for XML-aware diff
software, but so far I have never had enough of a problem with it
to make it necessary to take those steps.

Different people may well have had different experiences.  But the reason
I don’t know anything more sophisticated than git/svn/cvs for this kind
of problem is that they have been more than sufficient for the needs of
all the projects I’ve worked on over the years.

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

ron.vandenbranden
Administrator
In reply to this post by Ruchira Datta
Hi Ruchira,

I'm very interested in this discussion and would be interested to hear
how others are dealing with this, or perhaps get to know pointers to
promising tools for collaborative XML editing.

Op 25/10/2017 om 21:26 schreef Ruchira Datta:
>
> When two people edit a Google Doc simultaneously, Google Docs keeps
> the revision history, with a view that highlights changes, and it's
> possible to see who did what.  (However, it doesn't have Oxygen's
> author mode for viewing a TEI XML file, or any validation, etc.)
>

Given the fact that Google Docs documents can be exported to DOCX, they
can be converted to TEI from there. Although it's far from an advanced
XML editor, this could perhaps be helpful in a first stage for producing
shallow TEI documents. Yet, (custom) Word styles provide the most
structured approach to working with Word documents, which could count as
the closest equivalent to "tagless" XML editing (although there are
serious limitations, since -unlike XML tags- Word paragraph and
character styles can't nest with other character and paragraph styles).
Word styles can be processed during a conversion from DOCX to TEI, and
"upgraded" to TEI tags. Unfortunately, Google Docs uses a simplified
document format for real-time editing, which doesn't support custom
styles. Yet, I've briefly experimented with Microsoft's OneDrive, which
nowadays offers a online office suite that is advertised as "basic" but
seems to support custom Word styles present in a document.

So, if custom Word styles are suitable to your project needs (for e.g.
identifying basic structural text divisions, small information units
such as proper names, etc.), Microsoft's Word Online editor seems to
provide a possible starting point for:
     -collaboratively editing DOCX files
     -converting those DOCX files to TEI, with custom XSLT templates for
conversion of custom Word styles to the desired TEI tags
Although I don't know how the version history of Word Online compares to
Google Docs' revision history. Perhaps Dropbox (which seems to offer
editing capacities for DOCX files via Word Online as well) provides
revision history features more comparable to Google Docs.

Phew, just my 2 cents (and I never would have believed I'd be advocating
for Word/Microsoft/... in this life).

Another close relative is the XMLmind XML editor, which provides a
(cusomizable) author mode under a free personal license
(http://www.xmlmind.com/xmleditor/download.shtml). It has a Google Drive
connector, meaning that you can edit files stored on (a shared) Google
Drive location. However, the editor itself doesn't have real-time
collaboration features, so any concurrent changes would overwrite each
other.

Best,

Ron
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Martin Holmes
Hi all,

I think it's worth saying that what Google Docs enables us to do in this
regard is pretty astonishing. I have once in a while tried to imagine
the software architecture that enables this sort of live multiple-editor
functionality, and it makes my brain hurt. One reason it's so effective,
and usually so apparently seamless, may be that it can draw on Google's
huge resources and connectivity. It's easy to think that because Google
has done it, it would be easy for someone else (such as our friends at
Oxygen) to do in the same way, but I don't think that's the case.

Cheers,
Martin

On 2017-10-25 02:23 PM, Ron Van den Branden wrote:

> Hi Ruchira,
>
> I'm very interested in this discussion and would be interested to hear
> how others are dealing with this, or perhaps get to know pointers to
> promising tools for collaborative XML editing.
>
> Op 25/10/2017 om 21:26 schreef Ruchira Datta:
>>
>> When two people edit a Google Doc simultaneously, Google Docs keeps
>> the revision history, with a view that highlights changes, and it's
>> possible to see who did what.  (However, it doesn't have Oxygen's
>> author mode for viewing a TEI XML file, or any validation, etc.)
>>
>
> Given the fact that Google Docs documents can be exported to DOCX, they
> can be converted to TEI from there. Although it's far from an advanced
> XML editor, this could perhaps be helpful in a first stage for producing
> shallow TEI documents. Yet, (custom) Word styles provide the most
> structured approach to working with Word documents, which could count as
> the closest equivalent to "tagless" XML editing (although there are
> serious limitations, since -unlike XML tags- Word paragraph and
> character styles can't nest with other character and paragraph styles).
> Word styles can be processed during a conversion from DOCX to TEI, and
> "upgraded" to TEI tags. Unfortunately, Google Docs uses a simplified
> document format for real-time editing, which doesn't support custom
> styles. Yet, I've briefly experimented with Microsoft's OneDrive, which
> nowadays offers a online office suite that is advertised as "basic" but
> seems to support custom Word styles present in a document.
>
> So, if custom Word styles are suitable to your project needs (for e.g.
> identifying basic structural text divisions, small information units
> such as proper names, etc.), Microsoft's Word Online editor seems to
> provide a possible starting point for:
>      -collaboratively editing DOCX files
>      -converting those DOCX files to TEI, with custom XSLT templates for
> conversion of custom Word styles to the desired TEI tags
> Although I don't know how the version history of Word Online compares to
> Google Docs' revision history. Perhaps Dropbox (which seems to offer
> editing capacities for DOCX files via Word Online as well) provides
> revision history features more comparable to Google Docs.
>
> Phew, just my 2 cents (and I never would have believed I'd be advocating
> for Word/Microsoft/... in this life).
>
> Another close relative is the XMLmind XML editor, which provides a
> (cusomizable) author mode under a free personal license
> (http://www.xmlmind.com/xmleditor/download.shtml). It has a Google Drive
> connector, meaning that you can edit files stored on (a shared) Google
> Drive location. However, the editor itself doesn't have real-time
> collaboration features, so any concurrent changes would overwrite each
> other.
>
> Best,
>
> Ron
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Janelle Jenstad
For what it's worth, I'm not a programmer or even a very technically-minded scholar, but I've taught dozens of students to use SVN repositories. I learned from Martin Holmes, who wrote the documentation for MoEML's repositories. The documentation is so good that other projects use it to guide their students through setting up Collabnet Subversion: http://mapoflondon.uvic.ca/subversion.htm#subversion_intro. If you are hesitant, try his documentation first.

I use GoogleDocs and occasionally DropBox's new tools for co-writing, but all my digital projects are under version control in SVN repositories. Generally, I break my teams into subdomains so they are not likely to be working on the same file at the same time. We develop protocols for checking to see who is in the files that we all have to access. That doesn't help answer Ruchira Datta's original question, but may suggest some other ways of working that obviate the problem.

Best,
Janelle




-----Original Message-----
From: TEI (Text Encoding Initiative) public discussion list [mailto:[hidden email]] On Behalf Of Martin Holmes
Sent: October 25, 2017 3:50 PM
To: [hidden email]
Subject: Re: Collaboratively Editing a TEI XML Document?

Hi all,

I think it's worth saying that what Google Docs enables us to do in this regard is pretty astonishing. I have once in a while tried to imagine the software architecture that enables this sort of live multiple-editor functionality, and it makes my brain hurt. One reason it's so effective, and usually so apparently seamless, may be that it can draw on Google's huge resources and connectivity. It's easy to think that because Google has done it, it would be easy for someone else (such as our friends at
Oxygen) to do in the same way, but I don't think that's the case.

Cheers,
Martin

On 2017-10-25 02:23 PM, Ron Van den Branden wrote:

> Hi Ruchira,
>
> I'm very interested in this discussion and would be interested to hear
> how others are dealing with this, or perhaps get to know pointers to
> promising tools for collaborative XML editing.
>
> Op 25/10/2017 om 21:26 schreef Ruchira Datta:
>>
>> When two people edit a Google Doc simultaneously, Google Docs keeps
>> the revision history, with a view that highlights changes, and it's
>> possible to see who did what.  (However, it doesn't have Oxygen's
>> author mode for viewing a TEI XML file, or any validation, etc.)
>>
>
> Given the fact that Google Docs documents can be exported to DOCX,
> they can be converted to TEI from there. Although it's far from an
> advanced XML editor, this could perhaps be helpful in a first stage
> for producing shallow TEI documents. Yet, (custom) Word styles provide
> the most structured approach to working with Word documents, which
> could count as the closest equivalent to "tagless" XML editing
> (although there are serious limitations, since -unlike XML tags- Word
> paragraph and character styles can't nest with other character and paragraph styles).
> Word styles can be processed during a conversion from DOCX to TEI, and
> "upgraded" to TEI tags. Unfortunately, Google Docs uses a simplified
> document format for real-time editing, which doesn't support custom
> styles. Yet, I've briefly experimented with Microsoft's OneDrive,
> which nowadays offers a online office suite that is advertised as
> "basic" but seems to support custom Word styles present in a document.
>
> So, if custom Word styles are suitable to your project needs (for e.g.
> identifying basic structural text divisions, small information units
> such as proper names, etc.), Microsoft's Word Online editor seems to
> provide a possible starting point for:
>      -collaboratively editing DOCX files
>      -converting those DOCX files to TEI, with custom XSLT templates
> for conversion of custom Word styles to the desired TEI tags Although
> I don't know how the version history of Word Online compares to Google
> Docs' revision history. Perhaps Dropbox (which seems to offer editing
> capacities for DOCX files via Word Online as well) provides revision
> history features more comparable to Google Docs.
>
> Phew, just my 2 cents (and I never would have believed I'd be
> advocating for Word/Microsoft/... in this life).
>
> Another close relative is the XMLmind XML editor, which provides a
> (cusomizable) author mode under a free personal license
> (http://www.xmlmind.com/xmleditor/download.shtml). It has a Google
> Drive connector, meaning that you can edit files stored on (a shared)
> Google Drive location. However, the editor itself doesn't have
> real-time collaboration features, so any concurrent changes would
> overwrite each other.
>
> Best,
>
> Ron
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Richard Mahoney | Indica et Buddhica
In reply to this post by Ruchira Datta
Hello Ruchira,

Another option may be Perforce Helix:

https://www.perforce.com/

I've found Helix Core especially useful:

https://www.perforce.com/products/helix-core

It comes with P4Merge for diffs, its great.

https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge



Best, Richard





On Wed, 25 Oct 2017 12:26:13 -0700
Ruchira Datta <[hidden email]> wrote:

> Thank you all for your helpful replies!
>
> Indeed, my first job as a professional programmer was thirty years
> ago, and i personally like and use the git VCS.  I've been using it
> for my personal contributions in the solo phase of this two-person
> project.
>
> However, as far as highlighting specific changes, this approach
> generally uses diff, which is line-oriented.  I've been finding that
> Oxygen reflows the lines in the XML document (for instance, when
> switching between text and author mode, or when a word is added) in
> ways that i cannot predict or control.  This results in many lines
> being “changed” when it's really just a change to the whitespace.
> There are so many of these whitespace changes that trying to find the
> actual change is like trying to find a needle in a haystack.  I tried
> using the Oxygen “Compare Files” option, however this seems to be
> basically the same as diff and didn't help.  Large numbers of lines
> are highlighted as changed, where the only change is actually due to
> spacing and indentation.
>
> I've been muddling along with this, and i tried adding the repository
> to bitbucket and installing git on my collaborator's computer
> yesterday.  My collaborator is not the most tech-savvy person (even
> editing TEI XML files in Oxygen author mode is a bit of a struggle).
> Looking at the side-by-side diff might have been okay, except this
> whitespace issue makes it very hard to use.
>
> By the way, we found Dropbox also produces conflicted versions when
> two people edit the same Microsoft Word file at the same time (a bit
> like a VCS does).  I was personally impressed that it does this,
> however we don't find it practical.
>
> When two people edit a Google Doc simultaneously, Google Docs keeps
> the revision history, with a view that highlights changes, and it's
> possible to see who did what.  (However, it doesn't have Oxygen's
> author mode for viewing a TEI XML file, or any validation, etc.)
>
> My collaborator is used to using Track Changes in Word, so we were
> happy to find that Oxygen also has Track Changes.  Then it seems from
> the discussion so far, that the best option may be to keep the files
> subdivided and have one person acting as the master of each file at
> any given time, as Martin suggests.  (I was hoping to hear from you,
> Martin, as i had seen your reports about working on collaborative
> curation in the mailing list archives and thought you would probably
> have worked out the most practicable current solution.)
>
> Thank you all again for your help!  Will be happy to hear anyone else
> chiming in…
>
> —Ruchira
>
> On Wed, Oct 25, 2017 at 11:23 AM, Martin Mueller <
> [hidden email]> wrote:  
>
> > Echoing Gioele’s comment, it is with collaboration as with other
> > things in life. You preach water but drink wine.
> >
> > I don’t know what it is you’re editing, but I would be inclined to
> > chunk the XML source into bits that can be re-assembled and insist
> > that only one person edits one part at a time and there is one
> > person who is in charge of keeping the bits assembled in the proper
> > order.
> >
> > On 10/25/17, 12:48 PM, "TEI (Text Encoding Initiative) public
> > discussion list on behalf of Gioele Barabucci"
> > <[hidden email] on behalf of
> > [hidden email]> wrote:
> >
> >     On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:  
> >     > The main drawback I’m aware of is that some people (and so
> >     > possibly some of one’s likely collaborators) will need to
> >     > learn to use the version-control system, which can be tedious
> >     > for tham and for those they are collaborating with.  And some
> >     > people find the model of  
> > standard  
> >     > version-control systems counter-intuitive and very difficult
> >     > to internalize.  
> >
> >     Allow me to stress one particular point: What is most difficult
> > to grasp
> >     is the fact that
> >
> >     * there will be _conflicts_ at "merge time";
> >     * every synchronization made by any collaborator is an
> > opportunity for conflicts;
> >     * conflicts can be resolved only by those that have a deep
> > knowledge of the inner mechanisms of the used version control
> > system.
> >
> >     For example, hand editing XML files + git will often lead to
> > much head-scratching and utterances such as "this whole thing does
> > not work, what a waste of time".
> >
> >     The only way to use version control system with XML files is to
> > have a rigid workflow that minimize said conflicts (tiny changes,
> > frequent synchronizations, well defined work areas, only few
> > command allowed, etc). Parts of this workflow can be automated, but
> > meticulousness from all the collaborator is also required, as well
> > as a bit of studying.
> >
> >     Handling conflicts is what makes version control system much
> > more complicated than a Google Doc. However the investment in using
> > VCSes often pays off in many projects.
> >
> >     Regards,
> >
> >     --
> >     Gioele Barabucci <[hidden email]>
> >
> >
> >  
>




--
                              Richard Mahoney | INDICA ET BUDDHICA
                         Littledene  Bay Road  Oxford  New Zealand
                    T: +64-3-312-1699 | www.indica-et-buddhica.org
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Craig A. Berry-3
In reply to this post by Ruchira Datta
> On Oct 25, 2017, at 6:45 PM, Karl Billeter <[hidden email]> wrote:
>
> On Wed, Oct 25, 2017 at 08:50:57PM +0000, Craig A. Berry wrote:
> ...
>> Then there is the matter of attribute order.

> You could look at canonical form (--c14n in xmllint) but may find it too
> intrusive.

Thanks.  I had never looked into those options but now I will.

________________________________________
Craig A. Berry

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Gioele Barabucci-2
In reply to this post by Ruchira Datta
Hi Ruchira,

On 25/10/2017 21:26, Ruchira Datta wrote:
> When two people edit a Google Doc simultaneously, Google Docs keeps the
> revision history, with a view that highlights changes, and it's possible
> to see who did what.
Yes and no.

Google Docs produces a linear revision history for you to see, but this
is not how it works inside and this is the main difference between
snapshot-based version-control systems (anything you have used for
source code) and operation-tracking systems (most online stuff after
2007/Writely/Etherpad).

Google Docs and similar systems are able to resolve conflicts in a very
graceful way because they record every single keystroke the user types,
as well as contextual information and timestamps. This allows for highly
sophisticated conflict resolution mechanisms to be performed on the
server side. Technically speaking this technique is called Operational
Transformation (OT).

OT is much more complex that simple snapshot-based versioning but also
the only decent option for real-time editing. Sadly it requires a server
and a live connection to said server (the disconnected version of Google
Docs uses another bag of tricks).

If the oXygen people could implement OT it would be a great feature.

Regards,

--
Gioele Barabucci <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Gioele Barabucci-2
In reply to this post by Craig A. Berry-3
On 25/10/2017 22:50, Craig A. Berry wrote:

> On Oct 25, 2017, at 12:48 PM, Gioele Barabucci
> <[hidden email]> wrote:
>> The only way to use version control system with XML files is to have a
>> rigid workflow that minimize said conflicts [...] Parts of this
>> workflow can be automated, but meticulousness from >> all the collaborator is also required, as well as a bit of studying.
>
> Indeed.  Versioning XML documents is tricky business. You have to have
> complete control of line breaks, indenting, and attribute ordering.  I
> have been using xmllint like so to indent a file to have a single-space
> indent:
>
> and putting some version of that in a git pre-commit hook, so as far as
> the changes that git sees, differences only in non-significant
> whitespace should be eliminated.

Hi Craig, thank you for the concrete example.

This is exactly what I was referring to with "ridig workflow that can be
partially automated". Another example is the use of a different
diff/merge drivers like `p4merge` as other people mentioned in other
posts. They represent the part of the workflow that can be automated.

Unfortunately in git there is no way to centrally administer hooks and
filter. This means that every collaborator has to setup their
installation just right and make sure that all the used tools are
installed. Doable but non trivial in Windows and MacOS and a (small)
barrier to the entry of new "drive-by" collaborators.

SVN is a better solution in for this particular case because of its
centralized aspect with tons of opportunities to control what goes in
and what goes out. But then you pay the price of having to merge changes
manually after every single "svn update".

Tradeoffs, tradeoffs everywhere. :)

Regards,

--
Gioele Barabucci <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Collaboratively Editing a TEI XML Document?

Gioele Barabucci-2
In reply to this post by C. M. Sperberg-McQueen
On 25/10/2017 23:17, C. M. Sperberg-McQueen wrote:

>> On Oct 25, 2017, at 11:47 AM, Gioele Barabucci <[hidden email]> wrote:
>> On 25/10/2017 19:24, C. M. Sperberg-McQueen wrote:
>>> [...] And some people find the model of standard
>>> version-control systems counter-intuitive and very difficult to
>>> internalize.
>>
>> Allow me to stress one particular point: What is most difficult to grasp is the fact that
>>
>> * there will be _conflicts_ at "merge time";
>
> For the record - I agree that conflicts can be a pain [...] but my
> experience with shared editing of SGML and XML has not been anything
> like as dire as that pictured in this response of Gioele or the
> various responses of others.
>
> I am worried that anyone who finds this thread in future will
> conclude that using cvs or svn or git on XML documents is way too
> painful to be worth while. That has not been my experience.

Hi Michael, you are right, I painted a too dire picture.

Let me restate it more positively for posterity. :)

Keeping track of changes done to XML files with version-control systems
can be done and has been done with success.

As with other technologies, avoid fashion and always study the pros as
well as the cons of each solution before adopting them. In the case of
VCS it boils down to how difficult it is to set up the environment and
to manage editing conflicts. In most practical cases it is not a big
problem, for bigger projects it could be. There is no silver bullet.

If anybody wants to discuss ways to integrate revision control into
their XML projects, send me an email. VCS and diff algorithms are my
main research topic and part of what I do at the CCeH and at the DCH in
Cologne. I'll be glad to help.

Regards,

--
Gioele Barabucci <[hidden email]>
12