Notepad ++ XMLツールを使用してXSDを作成する

Question

現在、XMLツールのNotepad ++プラグインを使用しています。 XSDファイルのスキーマはW3によって普遍的に定義されているため、XSDファイルを検証するためにXMLツールを適切なスキーマに正しくポイントする方法を確認してください。これは私の現在のスキーマタグ宣言です：

<xs:schema 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
targetNamespace="https://www.w3.org/2009/XMLSchema/XMLSchema.xsd"> 

私は他のサイトで解決策を探してみましたが、解決策が見つかっていません。 This is my full XSD file as of now.私は、XMLツールが非ローカルURIの場所を解決できないと思っています。あるいは、XMLツールがXSDファイルをXMLスキーマとして正しく認識していないのですが、私は完全にはわかりません。私は単に何かを正しく宣言していない可能性もあります。

私はXMLファイルの検証時点ではありません。適切に形成されたXSDを作成しようとしています。

Answer 1

私が正しい場合、Schema for Schemasに対してXMLスキーマを検証しようとしています。

対象の名前空間は、XMLスキーマの名前空間である必要があります。接頭辞xs:にバインドされている名前空間と同じである必要があります。スキーマのスキーマを含むファイルの場所は、属性xsi:schemaLocationで指定できます。

<xs:schema 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    targetNamespace="https://www.w3.org/2001/XMLSchema" 
    xsi:schemaLocation="https://www.w3.org/2001/XMLSchema 
         https://www.w3.org/2009/XMLSchema/XMLSchema.xsd"> 

さらに一般的には、xsi:schemaLocation属性には、スペースで区切られた偶数のURIが含まれています。奇数位置の各URIは名前空間であり、次の偶数位置のURIはその位置ヒントです。 XMLスキーマ仕様では、xsi:schemaLocationという情報をスキーマ検証エンジンがそのスキーマを解決するかどうかを示すヒントとして定義しているため、この動作が100％保証される可能性は非常に高いことに注意してください。検証エンジンは、スキーマファイルの場所を解決する別の方法を自由に提供することができます。これを文書化する必要があります。しかし、エンジンにキャッシュにスキーマがない場合、広く確立されているので、xsi:schemaLocationのヒントを使用する可能性が非常に高いです。

一般的に、検証エンジンは、世界中のユーザーベースによって中央サーバーを指し示すスキーマの場所がサーバーに重大な負荷をかける可能性があるため、スキーマ（組み込みまたは一度限りのダウンロード）をキャッシュすることをお勧めします。 W3C。スキーマをローカルに置くことでレイテンシも減少します。エンジンがキャッシュされず、検証が頻繁に実行される場合、スキーマのスキーマをダウンロードしてローカルで使用することが考えられます。

最後に、XML Schemaのエンジンは、通常自動的に検証し、スキーマのスキーマに対しても仕様内のすべての更なる制約を考慮するだけでなく、使用時にスキーマをチェックします。そのような場合は、スキーマ内のスキーマの場所を指定する必要はなく、上記のすべてが自動的に行われます。しかし、それを明示的に行うことは素晴らしい知的運動です。

Answer 2

スキーマが正しいことを検証する最も良い方法は、それをスキーマプロセッサに送信することです。これは、単にスキーマのためのスキーマ・ドキュメント（S4SD）に対してそれを評価するよりもはるかに多くの完全なチェックを行います。 S4SDで表現できないスキーマには多くの制約があります。

実際、これらは2種類あります。<any>に課される条件に加え

：

例えばスキーマ文書のレベルで制約され

（1）スキーマ表現の制約、（XSD 1.1パート1§3.9.1） スキーマ文書のスキーマによる要素情報項目 namespace属性とnotNamespace属性の両方が存在してはいけません。

（2）ソース・スキーマ文書から生成されたスキーマ・コンポーネント・モデル上の制約で表されるスキーマコンポーネントの制約。一例は、コンテンツモデル内の2つの要素粒子が同じ名前を持つ場合、同じ型をも持たなければならないという、 "要素宣言の一貫性"制約（§3.8.6.3）である。

異なるスキーマプロセッサは、スキーマを検証するさまざまな方法を提供します。 .NETのサクソンとたとえばあなただけの（スキーマなしソースドキュメントを供給）

Validate -xsd:my-schema.xsd -t 

を行うことができますし、自分のスキーマにエラーがないかどうか、それはあなたを教えてくれます。