If one user marks a word as bold and another user marks the same word as non-bold, thereis no final state that preserves both users’ intentions and also ensures convergence
Having "bold" mean some semantics, e.g., important.
Then they merge. Alice does not consider it important, Bob does -> render both. E.g., Bob's "importance" expressed as bold, Alices "not important" as grayed text.
If the context has changed
E.g.,
"Ny is a great city."
Alice removes "great".
Bob wonts to replace it with "gorgeous", by removing "reat" and adding "orgeous".
Having merged:
"Ny is a orgeous city."
Begs for semantic intent preservation, such as "reword great to gorgeous".
Fig. 4
Uhh, I'd imagine "remove" would refer to "bold" annotation.
Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.
Syntactic intent is not preserved.
For example, a developer mightdecide that colored text marks should be allowed to overlap, with the overlap region rendering ablend of the colors
That would be better for user to decide.
I think a good default is to express semantics explicitly.
I.e., for Bob to not automatically state his utterance as important just because it's atop of Alice's, that she considers important.
If Bob tries to reword - ok. If Bob want to add - no.
No
Given Bold, Italic, Colored are syntactic representation of semantics that we do capture - they can overlap.
Moreover, in Bob's user-defined mapping from semantics to syntax, Bob's "important" can be bold, while Alice's "important" can be italic.
Conflicts occur not only with colors; even simple bold formatting operations canproduce conflicts
Again, let them capture semantics.
Say, "Alice considers "The fox jumped"" as important. Alice changes mind, only "The" is important. Bob considers "jumped" as important.
Result: Alice considers "The" important. Bob considers "jumped" important.
Consider assigning colored highlighting to some text
Color is meant to convey some semantics. Like "accent", or "important". These semantics can coexist, just like italic and bold.
So a solution may be to: 1. Let users express semantics of their annotations 2. Give user-customizable defaults of how they are to be rendered.
Ensuring, that semantics's render is composable. I.e., it conveys originally asigned semantics.
Furthermore, as with plain text CRDTs, this model only preserves low-level syntactic intent,and manual intervention will often be necessary to preserve semantic intent based on a humanunderstanding of the text
Good remark of syntactic vs semantic intent preservation.
Semantics are in the head of a person, that conveys them as syntactic ops. I.e., semantics get specified down to ops.
Merging syntactically may not always preserve semantics. I.e., one wants to "make defs easier to read by converting them to CamelCase", another wants the same but via snake-case. Having merged them syntactically, we get Camel-Snake-Case-Hybrid, which does not preserve any semantic intent. The semantics intent here are not conflict-free in the first case, though.
Make defs readable
| |
as CamelCase as Snake Case
| |
modify to CC modify to SC
They diverged at this point, even before getting to syntactic changes.
The best solution would be to solve original problem in a different way - let defs be user-specific. But that's blue sky thinking. Although done in Unison, we do have syntactic systems around.
So staying in a syntactic land, the best we could do is to capture the original intent: "Make defs readable".
Then we need a smart agent, human or an AI, specify it further.
The key idea is to store formatting spans alongside the plaintext character sequence,linked to a stable identifier for the first and last character of each span, and then to derive the final formattedtext from these spans in a deterministic way that ensures concurrent operations commute
I.e., let's capture user's intent as ops, not their result.