Domino のデータを共有する。フォーマットされたテキストのような問題を解決するには？
2020/6/27 - 読み終える時間: 3 分
2020年6月18日、OpenNTF 主催のイベントにおいて、HCL から数名の社員が参加して講演を行いました。その際に、今後に向けた取り組みの一つとして、Notes リッチテキストの互換性に関することが紹介されました。便利であり、Notes を特徴付ける項目のひとつであるリッチテキストについて、データの互換性をいかに確保していくかについて、研究がされています。
これについて書かれた英語版ブログ Sharing Domino Data: How Do You Solve a Problem Like Formatted Text? の翻訳版を掲載します。
本記事は、実現された製品に関するものではありません。今後に向けた、研究開発活動の一つであることにご注意ください。
翻訳者注: 概念的な内容について適切な翻訳が難しい部分がありました。理解が難しい場合は原文の参照をお願いします。途中に YouTube への参照があり、本内容の理解の補助となります。
Domino のデータを共有する。フォーマットされたテキストのような問題を解決するには？
2020年6月24日
著者: Paul Withers / Technical Architect, HCL Labs
Domino データを Notes/Domino プラットフォームの外で共有する際に、 Notes リッチテキストの再現忠実性は長い間問題となっていました。この問題について考える場合、一般的な出発点は、Notes リッチテキストのフィールドレンダラ/エディタと Notes リッチテキストアイテムの保存形式となるでしょう。しかし、これらはあまりに厳しい制約事項であり、その中でうまく収まるようなソリューションを見つけることは困難であり、私たちが考えられる範囲を越えています。
HCL Labs では、より根本的なアプローチをとっています。最近、新しいメンバーが入社してきたときには、箱の外で考えるのではなく、箱に火をつけるように指示されました。その結果、誰にでも合うとは限らないアプローチになってしまうかもしれません。しかし、私たちが Project Rosetta (社内の内部的なコンセプト実証プロジェクト) に与えられた使命は、Domino の外で使用するためのフォーマット化されたコンテンツの忠実性を保つための革新的なソリューションを見つけることであり、それにはひとつの必須条件がありました。デジタルソリューションのCTOであるジェイソン・ロイ・ゲイリーは、DNUG のローンチイベントと最近の OpenNTF のウェビナーでその成果を説明しました。40:27-50:44の10分間のプレゼンテーションはこちらからご覧いただけます。
用語について
初期のアクションのひとつは用語について非常に具体的にすることでした。Domino の読者にとって「リッチテキスト」という言葉は、Notes エディタや特定のストレージフォーマットと表裏一体の関係にあります。その結果、私たちは意識的に「フォーマットされたテキスト (formatted text) 」の扱いに言及する努力をしてきました。この件について議論している人には、間違った思い込みを避けるためにも、同じことをすることを強くお勧めします。
この間、2つのラジカルな選択肢がテーブルに残されていました。それは、Notes ではこのコンテンツのために別のエディタ/レンダラが必要になる可能性があるということと、既存のコンテンツがその利点を活用したい場合には、一度だけの変換が必要になる可能性があるということです。また、2つの重要な期待も認識していました。それは Notes リッチテキストを置き換えることを意図したものではないことと、既存の Notes リッチテキストをすべて変換する必要がないことです。なせなら、コンテンツが Notes クライアントでのみ使用されている場合や、サードパーティのソリューションがすでに問題を管理できている場合は、現状を受け入れられるからです。
出発点
Domino 以外の標準的なエディタには何があり、それらはどのようなフォーマットを使用しているのでしょうか？これは単純な質問のように思えますが、明らかになったのは、Notes リッチテキストエディタは 3 つの特定の目的のために使用されており、それぞれが特定のパラダイムと相互運用可能なフォーマットを持っているということです。
"1. 文書処理" (Document processing)
Domino では、ポリシーや手順書のような複雑で厳密にフォーマットされたコンテンツを管理するために、リッチテキストエディタやアイテムが使用されているのを時々見かけることがあります。そのようなコンテンツを扱うアプリケーションでは、変更追跡のような複雑な、文書処理機能を似せた設計がされています。Domino 以外では、このようなコンテンツは通常、Microsoft Word や HCL Connections Docs、Google Docs、Collabora などの共同編集ツールなど、特定の文書処理ツールで管理されています。
長年の抵抗の末、各ベンダーは相互運用性のための標準フォーマットである OOXML に移行しました。このストレージ・フォーマットには、文書処理エディタではオープンに編集できない、著者やタグなどのメタデータが含まれています。しかし、これらのメタデータは固定されており、範囲も限定されています。エディタはカスタムメタデータの操作を許可していません。また、エディタは一度に1つのファイルを編集することしかできません。
「一度保存すれば、どこでも共有できる」という試みにもかかわらず、セキュリティやアクセスの複雑さから、コンテンツがコピーされてしまうことがよくあります。ドキュメントは、すべての画像や埋め込みファイルなどが含まれた、1つの目立たないパッケージとして送信されます。これは一般的に、HTTPや電子メールの送信には大きすぎるファイルの結果となります。そのため、ユーザーはファイルを圧縮するか、Connections のような製品や SFTP のような一時的な転送プロトコルなど、安全なファイル共有ソリューションにコピーする必要があります。
これは非常に特殊なパラダイムであり、事実上メタデータを追加せずにリッチテキスト項目だけでフォームをマッチングさせるというものです。私たちはこれが有効なユースケースであることを認めていますが、狭義のユースケースです。その場でレンダリングしながら、Microsoft Word のような外部エディタで編集できるような形式でコンテンツを保存できないかどうかを調査するのは興味深いことです。しかし、それは現在のスコープとしては適切ではありませんでした。
2. メール
メールは常に Notes/Domino の中核をなすものでした。Domino が発売された当時、メールはまだ広く使われていませんでした。実際、MIME が定義されたのは 1992 年になってからです。しかし、MIME は Domino 以外での相互運用性のためのデファクトスタンダードとなっています。Domino の外からメールを受信した場合、それは MIME として保存されます。Domino ドメインからのメールのみが Notes Rich Text として保存されます。
繰り返しになりますが、特定のメタデータがありますが限定されています。MIME メールの場合、アドレスが保存されるアイテムタイプは Text ではなく、RFC822 Text です。これは Domino 内部では別のデータ型ですが、Notes クライアントは (おそらく) 特定の方法で解釈するようにプログラムされています。それは興味深く、有益な情報です。
ストレージ構造もこのユースケースでは非常に特殊です。メールは送信者のみがソースから参照されます。他の誰もが自分のメールのコピーを受け取ります。すべての受信者が参照する「単一バージョンの真実」を保存しようとしたことはありません。その結果、流通するのは、文書処理と同様に、テキスト、画像、ファイルを含む単一のパッケージとなります。そのため、最近の多くのメールは外部画像を参照したり、Connections Files や Box のような中央サービス上のファイルにリンクしたりしています。
これもまた、非常に特殊なパラダイムであり、アプリケーションの典型的な使用法とは一致しません。Domino がこのコンテンツを Notes リッチテキストではなく MIME として保存し、Notes クライアントに Notes リッチテキストではなく MIME を使用する代替のエディタ/レンダラがあれば、メールの相互運用性はより簡単になるでしょうか？それは現在の調査の範囲を超えています。しかし、繰り返しになりますが、このタイプのコンテンツは対象外となりました。
3. フォームのフィールドでフォーマットされたコンテンツ
第三のシナリオは、フォーム内の任意のフィールドでフォーマットされた内容です。エディタは文書処理ツールでもメールクライアントでもありません。様々なエディタが使用されていましたが、出力は 2 つのカテゴリに分類されます。HTML とマークダウンです。
マークダウンの編集には、2 種類のエディタがあります。最初のタイプは IDE (VS Code) またはスタンドアロン (Joplin) のエディタで、これらはマークダウンファイルのみを編集するように設計されています。文書処理ツールと同様に、これらは対象外です。2 番目のタイプは、OpenNTF の Web サイトやブログの Stephan Wissel のコメントエリアのエディタのように、アプリケーションに埋め込むことができるマークダウンエディタです。これらは Domino アプリケーションのためのエディタの種類とより密接に関連しています。また、TinyMCE のような HTML としてコンテンツを提供するエディタや、Vaadin リッチテキストエディタのようなフレームワーク固有のエディタとも密接に対応しています。
ドキュメントプロセッサやメールエディタとは、他にもいくつかの重要な違いがあります。第一に、コンテンツはコピーされることを意図したものではなく、参照されることを意図したものです。第二に、画像とファイルの添付ファイルは通常別々に保存されているため、コンテンツを表示しているクライアントが何であれ、それらをキャッシュすることができます。実際、WordPress のようなブログプラットフォームでは、これらのリソースを別々に保存することが義務付けられており、エディタはこれを強制しています。Domino でも、Declan Lynch 氏の Blogsphere テンプレートは、アセットを別々に保存するというアプローチをとっています。第三に、1 つのフォームに複数のフォーマットされたテキストエディタがあるかもしれません。第四に、フォーマットされたコンテンツに隣接するメタデータ、つまり他のフィールドはランダムであり、2つのフォームに同じメタデータが含まれることはほとんどありません。
以上の三つが Project Rosetta がターゲットとしたシナリオです。この分析からわかるように、Notes リッチテキストエディタとアイテムの機能には重要な違いがあります。しかし、私たちが対象としたユースケースは、Domino 以外で共有することを意図したコンテンツのみを対象としています。
アーキテクチャーの選択
私たちの概念実証には単純な目標がありました。コンテンツを HTML またはマークダウンとして管理し、理想的には両者を変換して Domino に保存できるようにすることの実現可能性を探ることです。
通常、コンテンツはどちらか一方で入力されます。マークダウンは、意味づけされた基本的なフォーマットで素早く編集するための、素晴らしい柔軟性のあるアプローチであり、利用する場面でも興味深いものになるでしょう。また、ノートブロックのような HTML では容易に利用できない、マークダウンで利用可能な選択肢もあります。しかし、例えばマーケティングや HR のユーザーがコンテンツをマークダウンとして入力することを期待することは現実的ではないことも理解しています。マークダウンと HTML とその逆の間で変換することはこの問題を解決し、Domino のローコードビジョンのために議論されてきたローコード/プロコードの往復アプローチに類似しています。
私たちは、Project Keep の上に API レイヤーを構築しました。私たちが抱えていた課題は、他のフィールドと共にこのコンテンツを送信する場合、どのようにして保存すべきデータ型を決定するかということでした。Keep や Domino HTTP では、添付ファイルはすでにアップロードされ、フィールドデータへのアクセスについては、別個の REST 呼び出しで取得されていした。そこで、ここでも同様のアプローチをとりました。この時点でのフローは、1回の呼び出しでドキュメントを作成し、別の呼び出しで添付ファイルや画像をアップロードし、Content-Typeを "text/ HTML "または "text/マークダウン"としてフォーマットされたコンテンツをアップロードまたは取得するというものです。これは変更できますか？もちろんです。
技術的には、Keep は Java であり、Java では HTML 操作のための標準ライブラリーは JSoupであり、マークダウン変換のための標準ライブラリーはflexmarkです。
サーバー上の2つの出力タイプの間でこの操作を維持する利点は、クライアントが HTML またはマークダウンを話す必要があればよいことです。マークダウンの異なるフレーバー (方言) は将来的に課題となるかもしれませんが、それは先の話です。アプリ開発者にしてみれば、かれらは独自のエディタを持っていて、私たちは一貫した変換を提供するわけです。サーバー上で処理することで、HTML をクリーニングするフェーズも可能になります。これは、現時点ではお話しできませんが、多くの潜在的な革新的な機会を開くことになるので、私はこの方法を維持することを特に強く望んでいます。
確かに、誰も解決できないような問題を解決しようとしているのかもしれません。しかし、研究開発とは、問題を別の方法で考え、これまでに提案されなかった解決策を考え出すことです。イカルスのように、より高く飛ぶ勇気があっても、落ちても構わないということです。
モバイルから Web へ、そして生の HTML /マークダウンの上に適切なエディタで Nomad が何を扱えるかを考え、Webへ、そしてモバイルへと戻っていくデモで、私たちがやろうとしていたことは達成できたと思っています。確かに完全なものではなく、Notes クライアント/Nomad 上での作業が必要になります。そして、私が言ったように、これはすべてのシナリオをカバーしているわけではありません。しかし、より普遍的なものを使って、Notes リッチテキストの特殊性なしに Domino にフォーマットされたコンテンツを出し入れできることを実証しています。これは、非 Domino データベースから NSF にフォーマットされたコンテンツを移行するための新しい方法を開き、非伝統的 (non-traditional) な聴衆にアピールしています。また、セッションの最後に Jason が示したように、フォーマットされたコンテンツのために Notes Rich Text を超えて考えることは、EWS (Exchange Web Services) のような非伝統的 (non-traditional) なクライアントや転送フォーマットのための要件です。