On 10/11/07, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On 10/7/07, Jürgen Ragaller <[EMAIL PROTECTED]> wrote: > > The topic of this thread was preventing editors from easily and > > frequently leaving documents locked. Removing locks eliminates that > > issue. > while you're on the soapbox anyway, could you elaborate on how you are > going to merge (or avoid or whatever) simultaneous edits? if i > understand the problem correctly, this requires intimate knowledge about > the xml grammars involved, hence a new merging (or clash detection) > algorithm would have to be written for every custom xml format. that > sounds non-trivial to me. > for wikis, this is not too hard, because you have just one very limited > grammar to deal with. but for arbitrary xml formats? > Jörn Nettingsmeier
I expect the design will mature. The first (current) version journals -- every save creates a new revision. This avoids locking and ignores the merge problem without losing data -- the "other" version is available, but any merging is manual. The next improvement will mark documents with unresolved branches. Each revision has a parent revision. Admins will have a view to find and fix documents with conflicts. A conflict document (translation) has two revisions with the same parent. Your design is the ultimate goal. Some doctypes can automatically merge revisions if the sets of changed fields do not intersect. Some fields may be configured for SVN-like merging. Any problems revert to marking a conflict. Knowledge of the XML format is only needed if the default merge algorithm is not appropriate. The default is likely elements within two levels from the root. Some doctypes may consider every element to be a "field". Some may allow each property to be a "field". An example of that last option: ORIGINAL: <myElement x="1" y="A"/> EDIT1: <myElement x="2" y="A"/> EDIT2: <myElement x="1" y="B"/> MERGE: <myElement x="2" y="B"/> Obviously this level of merging is not appropriate for every element in every doctype: ORIGINAL: <myElement employee="Paul" salary="100000"/> EDIT1: <myElement employee="Paul" salary="200000"/> EDIT2: <myElement employee="Jorn" salary="100000"/> MERGE: <myElement employee="Jorn" salary="200000"/> With the original design, each doctype can have a specific edit screen so a field like "employee" may not be changed. I would prefer configuring the new doctype without programming. The configuration would mark what is a "field" for merging and which fields may not be changed. The merge code is easy; designing a configuration system easily understood by humans will be a challenge. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
