2009-04-27 8 views
1

私たちはXMLを使用して、図形作成ツールに表示できる内容を制御するためのスキーマを定義しています。スキーマファイルは、ダイアグラムに配置できるオブジェクトの種類、それらのリンクの仕方、およびこれらのオブジェクトのプロパティ(つまり、エディタで設定できるプロパティ)を指定します。xml:複数レベルです!ENTITYの使用は可能ですか?

新しい種類の図が必要な場合は、新しいスキーマが作成され、.xsdに対して検証されます。スキーマファイルをモジュール化して保守しやすくするために、宣言を使用して別々のファイルをインクルードしています。特定の図要素上に一緒に属しているが、スキーマ内のいくつかの場所に存在する可能性のあるプロパティなどのリストは、別々のxmlファイルに書き込まれ、関連する場所にインクルードされます。セイ:

<!-- Nameing etc. just as an example --> 
<!ENTITY CommonProerties1 SYSTEM "file:../CommonProperties1.xml"> 
<!ENTITY CommonProerties2 SYSTEM "file:../CommonProperties2.xml"> 

、その後、どこかのスキーマ内:

<Node shape="Square"> 
    &CommonProperties1; 
    <!-- Specific properties go here --> 
</Node> 

これは難しい維持作るコピーPAT変換多くのものを防止し、かつcommmpn性質があまりにも複数のスキーマと共有することができます。

問題は今、いくつかの一般的なプロパティには、フラグや列挙型などの基本要素も含まれています。各ファイル(「CommonProperties1.xml」など)に"CommonEnums.xml"のような別の基本セットですが、!ENTITY宣言を使ってこれが可能ではないと思います。

!ENTITYを!DOCTYPEヘッダーの外側に宣言することはできません。ヘッダーを追加すると、ヘッダー宣言がファイルを介して1.2行を取得するため、最上位のxmlファイルが無効になります。

誰もこれまで同様のことをやろうとしましたが、問題を解決するために何をしましたか?私は行方不明の良いオプションがありますか?

XAN

答えて

3

一般的なシステムエンティティがテキストとして使用するように設計された任意の助け

乾杯は、/交換機構を含みます。私は深く複雑なボイラープレートを持つネストされた構造を見てきました。

問題の内容を少し詳しく見ていきましょう。

あなたの例では、エンティティの参照が&のCommonEnumsが含まれるエンティティが解析されるときに認識されるように、ドキュメントタイプ宣言でCommonEnumsの!ENTITY宣言を使用できないと思われるのはなぜですか?宣言に問題があるこれらのシステムエンティティについて特別なものは何ですか?あなたの目標が文書のプロローグの解析中にそれらを宣言しなければならないのを避けることであるならば、それを回避することはできません。

あなたは!DOCTYPEのヘッダ

これはある意味で真であるの外!ENTITYを宣言することはできませんが、便利な抜け穴があります。外部DTDで一般的なエンティティを宣言することができます。その場合、その宣言はドキュメントのプロローグに物理的には表示されません。これがあなたの状況に役立つかどうかは分かりませんが、外部の一般的なシステムエンティティをDTDに宣言すると、それらを参照するドキュメントインスタンスとフラグメントからそれらを「隠す」ことができます。

あなたの目標が再利用性、モジュール性、および簡潔さと思われる場合は、外部DTDを使用して必要なことを行うことができると思います。しかし、この機能を利用するには、XMLプロセッサを満たすために必要な範囲で、DTDを作成するすべての作業を行う必要があります。おそらくDTDに対する文書構造の検証を主張するでしょう。

+0

私たちが望んでいたことをすることはできません、あなたのアドバイスのおかげで。 – xan

関連する問題