0

これは特定のプログラミングの質問ではなく、何かを行うための適切な方法を知るための要求です。

「TheSomething」：私のコードは、XMLを標準出力として出力するユーザー提供のPowerShellスクリプトを実行します。この出力は、ソフトウェアのセットアップルーチンの一部として公開および提供するスキーマに準拠していると想定されています。出力でバージョンをサポートしているため、顧客のXMLは、XMLのルートにあるバージョン2の出力に対して次のようになります。

<my_report version="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mycompany.com/permanent/config-2.0.xsd config-2.0.xsd">

顧客の出力XMLは有効なXMLではない可能性があります（したがって、使用する前に検証する必要があります）。

私の目標は、バージョン属性の値を取得し、それが提供された適切な.xsdファイル名と一致することを確認してから、その.xsdファイルを使用して出力XMLを検証することです。

出力XMLが有効でない可能性があるため、XElement.Parse（）のようなものに依存してXMLを変数に変換して操作することはできません。したがって、私の唯一の手段は、最初の要素（my_report）を解析し、文字列操作を使用して決定を行うことだと思います。

注：コードが動作するマシンは、インターネットアクセスが保証されていません。

私の基本的な質問：これは正気の考えですか？私はこのようなことをするために雑草の中を離れていますか？それが正気でない考えであるならば、何が良い代替案でしょうか？

プラットフォームは、Windows Server 2008 R2、C＃4.0コンソールアプリケーションタイプです。

4

1 に答える 1

0

通常、Xmlドキュメントのバージョン管理には、名前空間を使用します。このアプローチでは、各バージョンに独自の名前空間と独自のXsdがあります。Xmlドキュメントを検証するには、すべてのXsdドキュメントを1つのスキーマセットにロードし、xmlを検証します。それは理想からはほど遠いです（ドキュメントは異なるバージョンであるにもかかわらず、意味的にはまったく関係がなく、通常は以前のバージョンの上に構築された新しいバージョンなどですが、多くの複雑さを追加します）が、それでも最も一般的なことだと思います。上記のアプローチを採用したバージョン管理に名前空間のないxmlドキュメントをすでに使用している既存のシステムに検証を後付けする場合は、アプリに多くの変更が加えられます（xmlファイルを送信する顧客による変更は言うまでもありません）。バージョンを見つけるには、最初にXmlReaderだけを使用できます。ルート要素に移動し、名前が期待どおりであるかどうかとバージョン属性（またはスキーマが予期しないルート要素を持つドキュメントを拒否するバージョンのみ）を確認します。次に、作成したXmlReaderインスタンスをスローし、検証用に新しいインスタンスを作成します（場合によってはドキュメントをロードします）。実際にドキュメント全体を読んでバージョンを検出するのではなく、ルート要素だけを検出するため、これは安価なはずです。ドキュメントが有効なXmlドキュメントでない場合（たとえば、ルートノードがない場合）、XmlReaderはそれを検出します。投げる。次に、作成したXmlReaderインスタンスをスローし、検証用に新しいインスタンスを作成します（場合によってはドキュメントをロードします）。実際にドキュメント全体を読んでバージョンを検出するのではなく、ルート要素だけを検出するため、これは安価なはずです。ドキュメントが有効なXmlドキュメントでない場合（たとえば、ルートノードがない場合）、XmlReaderはそれを検出します。投げる。次に、作成したXmlReaderインスタンスをスローし、検証用に新しいインスタンスを作成します（場合によってはドキュメントをロードします）。実際にドキュメント全体を読んでバージョンを検出するのではなく、ルート要素だけを検出するため、これは安価なはずです。ドキュメントが有効なXmlドキュメントでない場合（たとえば、ルートノードがない場合）、XmlReaderはそれを検出します。投げる。

于 2012-09-20T04:08:09.363 に答える