Idea
Fine Grained References+issues
This actually goes back to something Doug Englebart designed into the first hypertext systems. He said that pages should be addressable down to the paragraph level. Note that WikiMedia does have section level edit and link targets.
Another aspect of this is that paragraph level content can keep it's identity when moved from page to page, and when included.
Fine Grained References+solution
Assign an identifier to each chunk of text when it is saved. This can be done in conjunction with the cleaning of html tags which we do on the saving of most pages. These link targets can be stored as data- attributes inside of card content, and would need to be added as a field on the card table. I'm using data-purple in my current code-spike.
I'm thinking that it actually should be linked to the content, and sometimes be updated when the content changes, for example if you copy an entire card between Wagns or inside a Wagn, maybe the identifier comes with, but the intent is that small edits would always keep the original reference number.
Within a particular information space, these numbers should be unique, but the common practice is to start numbering from an origin (1), but to use an ecoding so they don't grow long quicky (e.g. base 36).
Fine Grained References+example
This came up again because I wanted something fine grained to identify chunks for interactive editing. I'm actually thinking I want to be finer grained that the original design of Purple Numbers, more like the phrase or sentence level, but I'm not sure yet. My thinking is that if it is fairly fine-grained, then edit conflicts will be rare. Each person will tend to be editing a different part of the document, making OT simple in most cases.
I expect more conflicts when doing bigger refactors where you are moving the blocks around, and that conflicts within a current block will be rare. Even when it happens, I want to keep each user editing their own buffer and try to resolve conflicts with a more merge-like operation at the end. I also think this will mesh better with the Federated Wiki ideas that Ward's group in inventing.
If we do this, I don't like the idea of creating some non-card object to deal with. Instead, I'd say it should be a virtual card identified by its relationship to a longer card. (And ultimately we should make it easy to graduate such cards into real cards.)
Fine Grained References+discussed in support tickets
Fine Grained References+relevant user stories