Saya mengembangkan aplikasi yang perlu menyimpan metadata inline , intext . Yang saya maksud dengan itu adalah sebagai berikut: katakanlah kita memiliki teks yang panjang, dan kami ingin menyimpan beberapa metadata yang terhubung dengan kata tertentu, atau kalimat dari teks tersebut.

Apa cara terbaik untuk menyimpan informasi ini?

Pikiran pertama saya adalah memasukkan dalam teks semacam Markdownsintaks yang kemudian akan diuraikan saat mengambil. Sesuatu yang terlihat seperti ini:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[@note this sounds really funny latin]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Ini akan memperkenalkan dua masalah yang dapat saya pikirkan:

1. Yang relatif kecil, adalah bahwa jika sintaks tersebut kebetulan kebetulan pada teks tersebut, itu dapat mengacaukan parsing.
2. Yang paling penting adalah ini tidak mempertahankan metadata ini terpisah dari teks itu sendiri.

Saya ingin memiliki struktur data diskrit untuk menyimpan data ini, seperti Tabel DB yang berbeda di mana metadata ini disimpan, sehingga saya bisa menggunakannya dalam cara-cara yang berbeda: query, statistik, pengurutan, dan sebagainya.

EDIT: Karena penjawabnya menghapus jawabannya, saya pikir mungkin baik untuk menambahkan sarannya di sini, karena itu adalah saran yang bisa diterapkan yang diperluas pada konsep pertama ini. Poster menyarankan untuk menggunakan sintaks mirip, tapi untuk menghubungkan metadata ke PRIMARY KEYdari metadatatabel database.

Sesuatu yang akan terlihat seperti ini:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[15432]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Di mana 15432akan ada IDbaris tabel yang berisi informasi yang diperlukan dan cukup, seperti contoh di bawah ini.

Pikiran kedua saya adalah untuk menyimpan informasi seperti ini di Tabel DB terlihat seperti ini:

TABLE: metadata

ID    TEXT_ID    TYPE    OFFSET_START    OFFSET_END    CONTENT
1     lipsum     note    68              79            this sounds really funny latin

Dengan cara ini metadata akan memiliki id unik, a text_idsebagai kunci asing yang terhubung ke tabel yang menyimpan teks dan itu akan menghubungkan data dengan teks itu sendiri dengan menggunakan rentang offset karakter sederhana .

Ini akan melakukan trik untuk menjaga data terpisah dari metadata , tetapi masalah yang dapat saya segera lihat dengan pendekatan ini adalah bahwa teks pada dasarnya tidak dapat diedit . Atau, jika saya ingin mengimplementasikan pengeditan teks setelah penugasan metadata, pada dasarnya saya harus menghitung penambahan karakter, atau menghapus dibandingkan dengan versi sebelumnya, dan memeriksa apakah masing - masing modifikasi ini menambah atau menghapus karakter sebelum atau setelah masing-masing metadata terkait.

Bagi saya, ini kedengarannya seperti pendekatan yang benar-benar tidak penting.

Apakah Anda memiliki petunjuk atau saran tentang bagaimana saya dapat mendekati masalah?

Sunting 2: beberapa masalah XML

Menambahkan kasus lain yang akan membuat cukup penting untuk pemisahan data dan metadata ini terjadi.

• Katakanlah saya ingin memungkinkan pengguna yang berbeda memiliki set metadata berbeda dari teks yang sama , dengan atau tanpa kemungkinan masing-masing pengguna benar-benar menampilkan metadata pengguna lain.

Solusi apa pun dari jenis penurunan harga (atau HTML, atau XML) akan sulit diterapkan pada titik ini. Satu-satunya solusi dalam hal ini yang dapat saya pikirkan adalah dengan memiliki DB Table lain yang akan memuat versi pengguna tunggal dari teks asli, yang terhubung ke tabel teks asli dengan menggunakan a FOREIGN KEY.

Tidak yakin apakah ini sangat elegan.

• XML memiliki model data hierarkis: elemen apa pun yang berada di dalam batas elemen lain dianggap sebagai anaknya , yang paling sering tidak terjadi dalam model data yang saya cari; dalam XML setiap elemen anak - anak harus ditutup sebelum tag induk dapat ditutup, sehingga tidak ada elemen yang tumpang tindih.

Contoh:

<note content="the beginning of the famous placeholder"> Lorem ipsum dolor sit <comment content="I like the sound of amet/elit"> amet </note> , consectetuer adipiscing elit </comment> , <note content="adversative?"> sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna Aliquam ERat volutpat.<note content="funny latin"> </note> </note>

Di sini kita memiliki dua masalah berbeda:

1. Elemen yang berbeda tumpang tindih: Komentar pertama dimulai dalam not pertama, tetapi berakhir setelah akhir not pertama, artinya bukan anaknya.

2. Elemen yang sama tumpang tindih: Nada terakhir dan huruf tebal bertumpang tindih; Namun, karena mereka adalah jenis elemen yang sama, parser akan menutup elemen yang terakhir dibuka pada penutupan pertama, dan elemen terbuka pertama pada penutupan terakhir, yang, dalam keadaan ini, bukan apa yang dimaksudkan.

Saya akan menggunakan campuran solusi Anda, tetapi saya akan menggunakan standar: XML. Anda akan memiliki sintaks seperti ini

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam <note content="It sound really funny in latin">nonummy nibh</note>
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Mengapa XML

Jika Anda memikirkannya, ini adalah bagaimana keseluruhan web terstruktur : konten (teks aktual) yang membawa semantik - apa yang Anda panggil metadata - melalui tag html.

Dengan cara ini Anda memiliki dunia yang sangat keren yang membuka:

• Parser gratis
• Pertempuran diuji cara untuk menambahkan metadata ke konten
• Kemudahan penggunaan (tergantung pada pengguna yang Anda targetkan)
• Anda dapat dengan mudah mengekstrak teks mentah, tanpa metadata, karena ini adalah fitur standar pada parser XML. Itu sangat berguna untuk memiliki versi konten Anda yang dapat diindeks, jadi Lorem <note>ipsum</note>dimunculkan ketika Anda mencari lorem ips*misalnya.

Mengapa XML melebihi Markdown

Situs web seperti stackexchange menggunakan penurunan harga karena semantik yang disampaikan kontennya agak mendasar: penekanan, tautan / url, gambar, tajuk, dll. Tampaknya semantik yang Anda tambahkan ke konten adalah

1. Lebih kompleks
2. Dapat berubah atau harus diperpanjang

Jadi saya rasa penurunan harga bukan ide yang bagus. Juga penurunan harga tidak benar-benar standar, dan parsing / dumping itu mungkin menyebalkan, bahkan lebih sintaks penurunan harga lihat posting Jeff Atwood tentang WTF yang dia temui di parsing Markdown .

Pada pemisahan antara data dan metadata

Per se, pemisahan seperti itu tidak wajib. Saya menganggap Anda mencari keuntungan yang dibawanya:

• Kemungkinan untuk memiliki konten mentah tanpa metadata
• Pemisahan masalah: Saya tidak ingin memiliki efek samping / kerumitan overhead saat memanipulasi metadata karena data, dan sebaliknya.

Semua masalah ini dihapus oleh penggunaan XML. Dari XML, Anda dapat dengan mudah membuang konten yang dilucuti tag, dan data / metadata dipisahkan, sama seperti atribut dan teks aktual dipisahkan dalam XML.

Juga saya tidak berpikir Anda benar-benar dapat memiliki metadata Anda sama sekali tidak terikat pada data Anda . Dari apa yang Anda jelaskan, metadata Anda adalah komposisi data Anda, yaitu menghapus data mengarah ke penghapusan metadata. Di sinilah Anda metadata berbeda dari HTML / CSS biasa. CSS tidak menghilang ketika elemen html dihapus, karena itu dapat diterapkan ke elemen lain. Saya tidak merasa ini adalah kasus dalam metadata Anda.

Memiliki metadata yang dekat dengan data, seperti dalam XML atau Markdown, memungkinkan pemahaman yang mudah (dan mungkin debugging) dari data. Juga, contoh yang Anda berikan pada pemikiran kedua Anda menambah kompleksitas, karena untuk setiap data yang saya baca, saya perlu meminta tabel metadata untuk mendapatkan ini. Jika hubungan antara data Anda dan metadata Anda adalah 1: 1 atau 1: N, maka itu IMO jelas tidak berguna, dan hanya membawa kompleksitas (kasus yang baik dari YAGNI).

Solusinya Gunakan Kasing

Saya tidak setuju dengan beberapa jawaban lain, hanya karena, sementara solusi hebat, mereka mungkin bukan solusi Anda . Ya XML memiliki markup kata dalam akronim itu, tetapi mungkin tidak ideal untuk situasi Anda. Itu terlalu rumit, ia menawarkan sedikit bantuan dalam menjaga meta data terpisah dari teks asli. Pada dasarnya itu akan mengubah segalanya menjadi bentuk metadata, membuat satu set data yang kelebihan berat badan.

Karena kemungkinan tidak ada solusi atau pendekatan yang sepenuhnya benar, solusi terbaik menjawab pertanyaan:

Bagaimana data akan digunakan oleh sistem?

Juga, jika Anda mencoba dan bertanya, bagaimana desain solusi dapat secara inheren menambah nilai sistem, dengan cara yang akan digunakan, maka Anda lebih dekat untuk menemukan jawaban elegan Anda .

Memahami masalahnya

Ok komentar yang cukup, mari kita gali masalahnya. Ini adalah masalah yang saya pahami (jelas menambahkan ini akan bermanfaat):

• Ada teks asli
  • Asumsi tentang teks asli ini:
  • Teks ini, mungkin atau mungkin tidak terdiri dari beberapa dokumen independen
  • Teks ini, mungkin atau tidak dapat diedit oleh satu atau lebih pengguna
  • Teks ini, berisi informasi terkait . Dengan itu saya berasumsi (koreksi saya jika saya salah) bahwa metadata terkait dan tidak deskriptif . Jadi ia menyimpan informasi yang terkait dengan teks asli, dan bukan informasi yang menggambarkan teks. Sehingga akan menyimpan catatan tentang teks asli, dan tidak dengan contoh menjelaskan bahwa teks adalah judul yang adalah berani dan merupakan link ke website, dll
  • Teks harus dengan mudah disaring berbeda dari metadata
  • Teks harus dilindungi dari rusak oleh, dan merusak metadata
• Seharusnya ada cara untuk menyimpan informasi yang terkait dengan teks asli (metadata)
  • Metadata ini juga membutuhkan metadata sendiri (meta), yang akan menyimpan informasi seperti pengguna (atau grup?) Yang mana data meta relevan untuk, seperti deskripsi metadata, katakan cuaca itu adalah catatan, atau komentar, atau deskripsi dll.
  • Metadata ini (dan metadata itu) perlu menahan perubahan dalam teks asli, perubahan metadata dan perubahan data meta (meta)
  • Metadata (+ Meta-Metadata) perlu terstruktur dengan baik dan mudah ditanyakan, dan diindeks atau bahkan digabungkan dengan cara relasional ke kumpulan data lain. Sifat relasional metadata tidak hanya terbatas pada Queries, tetapi juga memfasilitasi pembaruan atau menulis kembali dan perubahan metadata sebagai hasil dari aktivitas data relasional.
  • Nilai metadata (+ Meta-Metadata) dalam sifatnya sangat terkait . Itu menjadi langsung kontra produktif saat kehilangan hubungannya dengan teks asli. Jadi integritas hubungannya dengan teks asli adalah keharusan desain wajib.
• Asumsi lain tentang sifat masalah dan bagaimana itu akan digunakan adalah:
  • Akses sistem heterogen serentak. Dengan kata lain, pengguna mungkin ingin melihat teks dan mengedit metadata, pada saat yang sama dengan administrator (atau proses lain) melakukan kueri data relasional pada metadata terstruktur.
  • Sistem akan memiliki beberapa pengguna
  • Sistemnya modern. Artinya, itu tidak dibatasi oleh ruang penyimpanan, atau kecepatan pemrosesan, atau keharusan waktu nyata. Integritas dan fungsionalitas yang berfokus pada tujuan adalah prioritas yang lebih tinggi daripada keterbatasan sumber daya komputasi fisik.
  • Ada kemungkinan (walaupun rendah) bahwa penggunaan dan fungsionalitas sistem dapat berevolusi atau berubah, karena sistem digunakan.

Membangun desain solusi

Memahami masalah seperti yang telah saya uraikan di atas, saya sekarang akan mulai menyarankan solusi dan pendekatan yang mungkin yang bertujuan untuk memecahkan masalah di atas.

Komponen

Jadi saya akan melihat bahwa perlu ada sistem akses pengguna yang dibuat khusus. Itu akan menyaring metadata yang relevan dan tidak relevan dari teks asli. Ini akan memudahkan pengeditan dan tampilan metadata ke dalam teks. Itu akan memastikan integritas hubungan antara metadata dan teks aslinya. Ini akan menyusun metadata dan menawarkan sumber data ke sistem data relasional. Kemungkinan besar akan menyediakan sejumlah fungsi didorong tujuan lain.

Struktur

Jadi karena penting untuk menjaga integritas metadata ke teks asli, cara terbaik untuk memastikan hal ini, adalah menjaga metadata sejalan dengan teks asli. Ini akan menawarkan manfaat bahwa data asli dapat diedit dengan percaya diri tanpa merusak integritas ini.

Kekhawatiran dengan pendekatan ini adalah korupsi metadata oleh data asli dan sebaliknya. Pengindeksan dan penataan metadata yang memadai dan metadata (meta) sedemikian rupa sehingga memungkinkan untuk permintaan dan pembaruan serta akses yang efisien. Filter yang mudah dari metadata dari teks asli.

Dengan mengingat hal ini, saya akan menyarankan bahwa sebagian dari solusi didasarkan pada pendekatan menggunakan ESCAPE CHARACTERS dalam teks asli. Ini tidak sama dengan mendesain Bahasa Markup Anda sendiri atau menggunakan Bahasa Markup yang ada seperti XML atau HTML. Sangat mudah untuk merancang ESCAPE CHARACTER yang memiliki kemungkinan nol, atau hampir nol dalam teks asli.

Saran saya kepada Anda dalam hal ini adalah untuk dengan hati-hati mempertimbangkan data asli, dan mencoba dan menentukan sifat halaman kode yang menyimpannya dan kemudian mencari KARAKTER yang ideal atau URUTAN KARAKTER yang idealitu tidak mungkin atau tidak mungkin terjadi. Sebagai contoh di ASCII ada karakter kontrol bawaan dengan nilai byte yang tidak pernah digunakan dalam antarmuka pengguna standar. Hal yang sama dapat dikatakan untuk sistem informasi berbasis font atau data relasional. Berhati-hatilah dengan codec data biner. Bergantung pada sifat data asli, mungkin berharga untuk membuat parser yang mengonfirmasi penemuan urutan kontrol, mungkin dengan melihat data yang lolos dan memverifikasi integritasnya, baik dengan inspeksi sederhana terhadap struktur yang lolos. data, atau bahkan dengan memasukkan karakter kontrol yang dihitung untuk setiap urutan data yang lolos.

Contoh Data Dengan Escape Sequences

Ini adalah kisah tentang seorang pria. >>>> (#) Mengapa cerita ini tentang seorang pria bukan seorang wanita? (#) ( ) Userid :: 77367 ( ) Komentar Manajer ( ) DataID :: 234234234 >>>> Seorang pria yang pergi untuk memotong rumput, pergi untuk memotong rumput. Pria itu pergi dengan anjingnya >>>> (#) Tanyakan klien apakah cerita itu akan lebih baik dengan kucing sebagai gantinya (#) >>>> untuk memotong rumput. Jadi sekarang ini adalah kisah tentang seorang pria dan anjingnya yang pergi untuk memotong rumput.

Seorang pria dan anjingnya, pergi untuk memotong rumput, pergi untuk memotong rumput, sebuah padang rumput mencapai ke atas gunung. >>>> (#) Ini kedengarannya jauh lebih baik dengan hutan (**) Catatan Saran (#) >>>>

Laki-laki dan anjingnya dan misinya, untuk memotong rumput, padang rumput yang dicapai di atas gunung hanya tercapai ketika menyeberangi sungai.

Contoh Data Tanpa Urutan Escape

Ini adalah kisah tentang seorang pria. Seorang pria yang pergi untuk memotong rumput, pergi untuk memotong rumput. Pria itu pergi dengan anjingnya untuk memotong rumput. Jadi sekarang ini adalah kisah tentang seorang pria dan anjingnya yang pergi untuk memotong rumput.

Seorang pria dan anjingnya, pergi untuk memotong rumput, pergi untuk memotong rumput, sebuah padang rumput mencapai ke atas gunung.

Laki-laki dan anjingnya dan misinya, untuk memotong rumput, padang rumput yang dicapai di atas gunung hanya tercapai ketika menyeberangi sungai.

Jelas ini mudah diurai, tidak rumit sebagai bahasa Mark-up keseluruhan dan mudah beradaptasi dengan tujuan Anda.

Sudah Dipecahkan? Baiklah, saya akan mengatakan tidak. Solusi kami masih memiliki beberapa lubang. Akses pengindeksan dan terstruktur dari data ini buruk. Juga, tidak masuk akal untuk menanyakan file ini (atau beberapa file) bersamaan dengan mengeditnya.

Bagaimana kita bisa menyelesaikan masalah itu?

Saya akan menyarankan DATA ALOCATION TABLE sebagai header dokumen. Saya juga menyarankan untuk menerapkan TUE UPDATE TABLE UPDATE TRANSAKSI . Biarkan saya jelaskan. Perancang sistem file, khususnya sistem file disk rotasi, menghadapi tantangan desain yang serupa dengan yang telah Anda jelaskan di atas. Mereka perlu menanamkan informasi tentang file pada disk dengan, bersama dengan data. Solusi hebat untuk integritas hubungan data ini, adalah DUPLICATE dalam Tabel Alokasi File (FAT).

Ini berarti bahwa untuk setiap Item Metadata individual, ada entri yang sesuai di Tabel Alokasi Data . Jadi cepat, terstruktur dan relasional, dan independen dari data asli. Jika pertanyaan atau bergabung atau pembaruan perlu dilakukan pada metadata, maka itu mudah dilakukan dengan hanya mengakses Tabel Alokasi Data .

Jelas perhatian harus diberikan untuk memastikan bahwa metadata in-line asli adalah cerminan sejati dari data Tabel Alokasi Data. Di situlah Antrian Pembaruan Tabel Transaksional masuk. Setiap perubahan, penambahan atau penghapusan metadata, dilakukan bukan pada data itu sendiri, melainkan pada antrian. antrian kemudian akan memastikan bahwa semua perubahan dilakukan untuk data in-line dan tabel, atau tidak ada perubahan sama sekali. Ini juga memungkinkan pembaruan asinkron dilakukan, misalnya, semua metadata pengguna tertentu dapat dihapus dengan menjalankan perintah hapus pada antrian. Jika metadata inline dikunci dan digunakan, antrian tidak akan melakukan perubahan apa pun sampai bisa melakukannya untuk data Tabel dan data inline.

Ini adalah jenis pertanyaan teknik yang khas karena semua opsi Anda memiliki pengorbanan yang berbeda, dan mana yang terbaik tergantung pada apa yang penting bagi Anda. Sayangnya, Anda belum memberikan informasi yang cukup untuk membuat keputusan.

Anda juga tampaknya belum mempertimbangkan masalah semantik yang penting. Katakanlah teks aslinya

Teman saya Bob meminjamkan saya lima dolar

Seseorang menambahkan komentar di sekitar pepatah "Bob"

Bob benar-benar idiot

Kemudian teks asli diedit ke

Jane meminjamkan Bob lima dolar yang kemudian dipinjamkannya kepadaku

Anda mungkin memahami kasus ini menggunakan algoritma pencocokan teks seperti apa yang digunakan untuk menampilkan file diff, tetapi offset karakter akan membuat metadata melampirkan ke "Jan" di "Jane".

Lebih buruk adalah jika teks diedit ke

Teman saya Steve meminjamkan saya lima dolar

Anda bisa mengetahui cara melampirkan metadata ke "Steve", tetapi bagaimana Anda tahu jika itu berlaku?

Juga, sudahkah Anda memutuskan apakah metadata itu sendiri dapat memiliki metadata? Itu mungkin mengubah implementasi Anda.

Di luar masalah semantik, tidak terlalu jelas apa yang Anda lakukan dengan data. Saya pikir mungkin sangat tidak nyaman untuk memiliki teks asli "tercemar" dengan markup apa pun, tetapi kemudian Anda tidak masalah dengan memiliki nilai ID di dalamnya. Yang tidak masuk akal jika metadata berlaku untuk bagian teks alih-alih dimasukkan ke titik dalam teks.

Dugaan saya adalah bahwa untuk sebagian besar tujuan menyimpan teks yang ditandai lebih mudah, atau, pilihan kedua, menggunakan semua SQL dan memiliki teks dan markup yang diwakili oleh hierarki simpul - pada dasarnya DOM dalam bentuk tabel. Jika data Anda hierarkis daripada mungkin lebih mudah menggunakan XML dan mendapatkan parser yang ada secara gratis, dibandingkan menulis sendiri.

Sangat mungkin bahwa ada beberapa solusi yang cukup sederhana yang cukup baik untuk situasi Anda yang sebenarnya, tetapi saya tidak dapat memberi tahu Anda apa itu karena itu benar-benar tergantung pada apa yang Anda coba lakukan, secara detail.

Saya sangat menyarankan Anda merangkum strategi apa pun yang Anda pilih sebanyak yang Anda bisa, meskipun ini cukup sulit dilakukan jika banyak dari implementasi Anda perlu terlihat oleh banyak pertanyaan SQL.

Maaf bahwa balasannya begitu tersebar dan begitu penuh dengan "itu tergantung", tetapi pertanyaan desain dunia nyata seperti itu.

Saya pikir saran dari penjawab sebelumnya, yang Anda sebutkan pada pertanyaan Anda) adalah yang sangat bagus.

Itu akan berperilaku sama seperti kita memposting tautan di situs StackExchange, tetapi data info akan berada di tabel lain. Manfaatnya adalah, Anda memiliki data yang terpisah, dan karenanya dapat ditelusuri dan diindeks. Saat mengedit teks, Anda dapat memeriksa ID metadata yang dihapus dan membersihkan tabel metadata.

Satu-satunya masalah kecil seperti yang Anda katakan adalah penguraian, tetapi Anda bisa mengatasinya dengan mudah.

Katakanlah saya punya teks:

Anda hanya perlu duduk dan menonton setiap bulan, dan tidak ada biaya tambahan untuk layanan ini seperti yang Anda miliki di sini, atau karena itu terkait dengan erat volutpat.

Saya menambahkan catatan seperti ini:

Lorem ipsum dolor sit amet, consectetuer adipiscing elite, sed diam [@ 123, # 456,2w] bukan main nibh euismod tincidunt untuk laoreet dolore magna aliquam erat volutpat.

[@123,#456,2w]berarti: user_id = 123, note_id = 456, dan teks yang ditandai oleh note ini membentang untuk 2 kata berikutnya (bisa berupa karakter ( c), kalimat ( s), paragraf ( p) , paragraf ( ) atau apa pun). Sintaks yang tepat mungkin berbeda, tentu saja.

Dalam teks biasa editor catatan teks dapat dengan mudah disimpan di akhir dokumen, seperti halnya dengan catatan kaki Markdown.

Dalam editor teks kaya, catatan semacam ini dapat ditampilkan dalam teks sebagai ikon, dan teks yang ditandai dapat disorot dengan beberapa cara. Pengguna kemudian dapat menghapus catatan tersebut seperti karakter normal dengan Delatau Backspace, dan mengeditnya dengan semacam mode pengeditan khusus. Saya membayangkan mengubah ukuran area yang dicatat dengan mouse dan mengedit teks catatan dengan jendela sembulan.

Pro:

• Sesuai dengan "persimpangan" karena Anda menandai offset (tersirat oleh posisi note dalam teks) dan panjang untuk setiap note.
• Mendukung lingkungan multiuser. (Sebenarnya, ini membutuhkan penelitian lebih dalam dan Anda mungkin harus berurusan dengan sesuatu seperti transformasi operasional Google Wave , yang tidak bisa ditangani oleh otak saya.)
• Dapat diedit dengan editor teks kaya dan polos.
• Anda dapat dengan mudah menangani revisi, karena semua marker ada di tempat - saat Anda mengedit teks sebelum marker, marker hanya bergeser bersamaan dengan teks lainnya.
• Mudah diurai.
• Tidak perlu untuk DB eksternal, tetapi Anda masih bisa menggunakannya jika mau.
• Dapat dicampur dengan penurunan harga atau XML jika Anda memilih beberapa sintaksis yang tidak mencolok.

Kontra untuk pengeditan teks biasa:

• Anda tidak dapat melihat area dalam teks yang ditandai dengan catatan (kecuali jika Anda menyorot plaintext, yang merupakan opsi juga), tetapi hanya tempat di mana catatan dimulai. Ini dikompensasi oleh kemampuan untuk memilih satuan panjang sewenang-wenang: karakter, kata-kata, kalimat, paragraf.
• Anda dapat mengedit teks di bawah catatan tanpa memperhatikan, terutama jika catatan itu cukup panjang (misalnya 2+ paragraf). Dapat dikompensasi oleh mekanisme kontrol revisi yang membandingkan teks di bawah setiap catatan dengan versi sebelumnya dan memberi tahu pengguna jika diubah.

Kontra umum:

• Masalah dengan banyak pengguna mengedit teks yang sama, tapi saya pikir itu tidak bisa dihindari. Saya bukan ahli dalam bidang ini.