サイズが 50k から約 300k の XML があり、いくつかの変換を行う必要があります。変換には、一部の要素の別の場所への移動や、異なる要素の属性間のマージが含まれます。
私が知っている限りでは、理想的には XSLT を使用してこの変換を実行する必要がありますが、必要な変更の数が正確に保持されるデータの量に比べて無視できるため、出力 XSL を構築するための不要な作業が大量に作成されるのではないかと心配しています。同じ。
私の質問:
DOM 機能 (私は .net 3.5 で作業しています) といくつかの XPATH だけを使用して、これをそのまま実行することをお勧めしますか? サイズが小さくなるということは、必要な変更の数が増えると、コードが不必要に複雑になる可能性があるということです。
それでも XSLT を推奨する場合、入力 XML からチャンクを最初から再作成するのではなく、そのままコピーする方法はありますか?
ありがとうございました！
素晴らしい質問です。
ドキュメントに非常に小さな変更を加えたいだけの場合、XSLT が高価になる可能性があることは確かです。多くの反復変換を行う場合、コストは特に顕著になります。これは、各変換が前のデータセットをわずかに改善したデータセットを作成する最適化のユースケースで発生することがあります。
ただし、多くの場合、小さな変換を行うコストは、構文解析とシリアライゼーションのコスト (レキシカル XML をツリーに変換して戻す) によって支配されるため、構文解析とシリアライゼーションも含む他のアプローチ (DOM 更新または XQuery 更新など) を使用する必要があります。これ以上良くなることはありません。したがって、質問1への回答として、DOMを使用する方が良いとは思いません。改善を実現する唯一の現実的な方法は、XML データベースを使用することです。これにより、ドキュメントが字句形式ではなくツリー形式で永続的に保持されるようになったため、解析とシリアル化のコストを回避できます。
質問 2 では、はい、xsl:copy-of を使用してドキュメントのチャンクを変更せずにコピーできます。適切な XSLT プロセッサでは、これは非常に効率的です。確かに、ソース ツリーから結果ツリーへのこのコピーを行うコストは、ソース ツリーを構築するための解析や、結果ツリーを破棄するためのシリアライゼーションのコストよりもはるかに少ない可能性があります。(もちろん、実際の結果は XSLT プロセッサごとに異なります。)