なぜ XMLC か?

元来の XMLC の問題領域

• グラフィックデザイナーとプログラマーは別々のツールを使ってファイルを作成する別々の人たちである。 グラフィックデザイナーは HTML 編集ツールを使い、プログラマーはテキストエディターを利用する。
• グラフィックデザイナーは顧客に面した所で仕事を行い、HTML ファイルで模擬的なサイトを構築する。
• 最初の模擬的なサイトはプログラマーに手渡され、（つまりソースツリーの中に格納する） 動的な表現方法のロジックの開発が行われる。
• グラフィックデザイナーはそのまま、サイトの見た目や感じを改良する作業を進め、 ソースツリーの中に修正したサイトを格納する。

XMLC によって拡張された世界観

• HTML や XML ドキュメントの中のどんな場所でもテンプレートとして使え、 ダイナミックにコンテンツをページに加え、新しいドキュメントを創る。

XMLC の設計目標

• HTML や XML ドキュメントをオブジェクトに変換する、汎用性のあるテンプレート作成ツールであり、 内部に埋め込まれたコードというよりは、外部から操作可能となるようにする。
• HTML ファイルは規則にかなった HTML の要素だけで構成され、デザイナーに好まれる HTML の編集ツールでも大丈夫である。 模擬的なデータが動的に生成された物に置き換わるタグを識別する仕組みとして HTML の ID 属性を用いる。
• HTML ページはそのままサイトの有効な模造品としてあリ続ける。デザイナーは必要に応じてページを進化させ、 更新は動的なページを生成するために必要な情報を失うことなくプログラマーに渡される。 HTML は 標準仕様どおりの HTML 以外の物を含まないので、このことは自然と実現される。
• ページの動的な生成部分を変えないデザインの変更はソースコードに影響を与えるべきではない。 そのような変更が行われた時は実行時ではなく、コンパイル時に問題が検知される事になる。 こうした目標は動的なデータで置き換えられる事になるタグへのアクセスメソッドを生成することで到達できる。
• HTML ページは Java プログラマーにはリソースである。 Java プログラマーはオブジェクトやクラスを彼らにとってはごく自然なやり方で扱う。制御の流れは Java の手の中にあり、HTML ページの中で表示する順番に定義される物ではない。