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

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

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

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

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

<FOMT color=”black” >Helloont> 　　（存在しないタグ）
Hello　　　　　　　　　　　(閉じてない)
colorblack=” >Hello　　　　　（属性記述に間違い）
A

Hello　(インラインタグ内にブロックタグ)

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

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

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

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

「必ずタグは閉じてください」「属性値のダブルクオートも正しく閉じてください」というのは正当ですが、「<」や「”」が出力データに混じって出てしまうようなケースが容易に想像できます。タグや属性が正しく記述されていないと予想不可能な動作（エラーや無変換）になるようではミドルウェアとして脆弱すぎると言えます。またWebの特性上ユーザーの振る舞いによってはセッションは容易に切れます。ミドルウェアとアプリケーションはアプリケーションセッションで繋がっていながら、ユーザとミドルウェアの間のミドルウェアセッションが切れてしまうと一連のトランザクションの結果が不安定になります。様々な機能を実現するために、コンテンツ全体の厳密な構造解析を行うことや、独自セッション管理をすることは、実装上の都合からは理解できます。しかし、これを行ってしまうと、変換エラーと言うクリティカルな問題を抱えこんでしまいます。そのため、携帯コンテンツ変換のアーキテクチャーでは、次の方針が重要です。

コンテンツに言語仕様の厳密な遵守を要求してはいけない
セッションを使ってはいけない

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

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

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