Google Waveの動作変換が注釈が必要なのはなぜですか？

Question

Google Waveで使用される運用変換のものには、かなり奇妙なドキュメント形式があります。ドキュメントは、基本的にはXMLサブセットドキュメント、文字、タグを起動し、タグを終了するだけです。それに加えて、ドキュメントには「注釈」があり、これらは範囲に関連付けられたメタデータであり、例：開始位置と終了位置です。ホワイトペーパーは、次のような存在を正当化します。

Wave Document操作は、注釈もサポートしています。注釈とは、アイテムの範囲、つまり開始位置、および終了位置に関連するメタデータです。これは、基礎となる構造化されたドキュメント形式を不必要に複雑にしないため、テキストのフォーマットとスペルの提案を説明するのに特に役立ちます。

ドキュメントからの任意の範囲が選択され、たとえば太字である-XMLタグネストが厳密であり、オープンタグ挿入とクローズタグ挿入の混乱を引き起こす場合、それがいくらか難しいことを確実に見ることができます。

しかし、これです 本当 実際の問題？つまり、基本的に構造化された編集者ではなく、基本的に1年前のワードプロセッシングパラダイムを模倣するエディターを作成しない場合、そのような操作をサポートする必要がありますか？純粋なXMLは、単にHTML5としてドキュメント構造とともに変換されますか？スタイルがタグとしてドキュメントにあるパフォーマンスの問題ですか？または、オペレーショナル変換モデルは、タグで表されている場合、テキストのフォーマットで不十分な結果を何らかの形で生成しますか？

また、サイドの質問 - 純粋な「文字を挿入し、文字を削除し、保持する」運用変換モデルはどれだけ優れていますか？たとえば、html5をテキストとして編集するか、ウィキペディアの記事を編集しますか？

Answer 1

OTで階層マークアップ言語を使用することには根本的な問題があります。作業例については、以下を参照してください。

単純なテキストとして単純に扱われた場合、運用変換はHTMLなどの構造化されたドキュメントで機能しますか？

Answer 2

この選択は、いくつかの面での最適化として私にとって理にかなっています：

• 基礎となる文書は、人間が読みやすく、可能な限り解析可能なままです
• 基礎となるXMLを解析するアルゴリズムは、可能な限り単純なままです（結果のドキュメントを解析するグーグル以外の試みとの互換性、およびメンテナンスのために）
• 複数の編集の後、余分な収集されたゴミは、ドキュメントのタグや追加のパスの数が膨大であるため、それを簡素化しようとするため、大きなパフォーマンスヒットにつながる可能性があります。