携帯コンテンツ変換の選定基準：変換エラーと変換アーキテクチャー

コンテンツ変換システムにおいて、変換仕様はもちろん重要ですが、

正しい記述で変換仕様にのっとった例）
Hello　
→　Hello

実は、変換仕様「外」の振る舞いも、負けず劣らず重要です。

間違った記述の変換仕様外の例）

1. FOMT color=”black” >Helloont> 　　（存在しないタグ）
2. Hello　　　　　　　　　　　(閉じてない)
3. colorblack=” >Hello　　　　　（属性記述に間違い）
4. A
   Hello　(インラインタグ内にブロックタグ)

このような例は、意図せぬミスや勘違いやバグなどから発生しますが、どのように処理されるべきでしょうか？やはり一番良いのは、そこはスキップして次の正しい場所から変換されることでしょう。そして、いついかなる時もブラウザーまでアプリケーションが出力したレスポンスを出すことが重要です。

サーバ型にせよWeb組込み型にせよ、コンテンツ変換はレスポンスの通り道にいます。もし何らかの理由で途中にいるミドルウェアがエラーを返す可能性があるとすれば、アプリケーションの出力を遮ってしまうことになり、大きな問題となります。例えば、アプリケーションがDB更新処理をし、その結果を返す時に、HTMLの問題のためにミドルウェアからユーザーにエラーを返すのは好ましくありません。よって、次のことが言えます。

• 携帯コンテンツ変換は、変換エラーを起こしてはいけない

変換エラーが発生する可能性としては、２つのケースが考えられます。１つは元コンテンツの構造を厳密に解析し過ぎるケース、もう１つは独自のセッションを使っているケースです。

「必ずタグは閉じてください」「属性値のダブルクオートも正しく閉じてください」というのは正当ですが、「

ラウンドアバウトはこの問題を踏まえ、コンテンツ全体の厳密な構造解析はせず、単語検索をベースにしたテキスト解析のアーキテクチャーを採用しています。これに則ると、原理的にエラーが発生しません。入力コンテンツがXHTMLであろうとプレーンなテキストでも、宣言が無くても、タグの閉じ忘れがあっても、エラーは発生しません。実装上はバイナリーが通過してもエラーが起きない設計にさえなっています。決して破綻せず、常にコンテンツに合わせてベストエフォートの変換が可能です。また、もう１つの原因であるセッション管理は行いません。

• ラウンドアバウトは、どんな入力でも、原理的に変換エラーが発生しません
• ラウンドアバウトは、セッションを使いません

変換エラーの問題は、実装よりもむしろアーキテクチャーに左右される問題です。ラウンドアバウトは真にロバストな変換アーキテクチャーを備えた製品であり、安心して開発・運用することが可能です。