仮説と事実のダンプ→まとめ

Ｑ１．なぜ検索式はXPath1.0、XPath2.0、XQuery1.0をすべて書いてみたのか。
　　　→照会言語には上記の規格が存在するが、いずれかは目的を実現できないのでは？という懸念があった。
　　　→また、それぞれの規格のできること（メリット、デメリット）を見極める必要があった。

Ｑ２．なぜ検索式と検索対象であるXMLデータを作成したのか。
　　　→業務要件を満足する検索式は、検索処理自体が１通信で成立しないのではないか？という懸念があった。

そして、実施した結果があるはず。

Ａ１．検索式はいずれの規格でも目的を実現可能である。そして、同一通信回数で検索処理が成立する。

Ａ２．ただし、記述量に違いが現れた。

　　　XPath1.0は複数のシーケンスに対する繰り返し処理を実現する「for句」をサポートしていないため、記述量が膨大になる。
　　　同じ機能を実現するのに開発量が多くなることは、生産性、保守性の観点から望む姿ではない。
　　　よって、XPath1.0を採用したアーキテクチャは現実的ではないと判断した。

Ａ３．XPath2.0、XQuery1.0の記述量に違いは無かった。何が違うか。

　　　XPath2.0では、フィルタ（絞込み）処理を実現する「where句」がサポートされていない。
　　　→しかし、「if,then,else」キーワードに基づく条件式が同等の処理を実現するためデメリットにはならない。

　　　XPath2.0では、ソート処理を実現する「order by句」がサポートされていない。
　　　→今回の検索式は「order by句」を使わなくても実現できた。（XQuery1.0のメリットであることは事実）

　　　XPath2.0では、検索結果のシーケンスの構成を実現する「return句」がサポートされていない。
　　　→今回の検索式はrootIdリストを取得するのみで、複数項目（例えばrootIdとdocId）を取得する検索を想定していない。

本結果に関しては、判断条件が不足していることから、別の仮説を置いた上で検証を継続し結論を導く。
あー。バカじゃねーの、おれ。夜中に垂れ流しだな。。。