Notepad ++ XML 도구를 사용하여 XSD 만들기

Question

다양한 XML 문서 용 XSD 파일을 만드는 중입니다. 현재 XML Tools Notepad ++ 플러그인을 사용하고 있으며 XSD 파일의 유효성을 검사 할 때 it asks for XML Schema to validate against: 저는 아닙니다. 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 스키마의 유효성을 검사하려고 시도하고 있습니다.

대상 네임 스페이스는 접두사 xs:에 바인딩 된 네임 스페이스와 동일한 XML 스키마 여야하며 스키마 스키마가 포함 된 파일의 위치는 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 스키마 엔진은 스키마 스키마뿐만 아니라 사양의 모든 추가 제약 조건을 고려하여 스키마를 자동으로 확인하고 스키마를 검사합니다. 이 경우 스키마 내의 스키마 위치를 지정하지 않아도 위의 모든 사항이 자동으로 발생합니다. 그래도 명시 적으로하는 것이 좋은 지적 훈련입니다.

Answer 2

스키마가 올바른지 확인하는 가장 좋은 방법은 스키마 프로세서에 스키마를 제출하는 것입니다. 스키마 도큐멘트 용 스키마 (S4SD)에 대해 평가하는 것보다 훨씬 철저한 검사를 수행합니다. S4SD에서 표현할 수없는 스키마에는 많은 제약이 있습니다.

사실이 두 종류입니다.

(1) (예를 들어, XSD 1.1 부 1 §3.9.1) 스키마의 문서 레벨에서 제한되어스키마 표현 제약 :

<any>에 부과 된 조건 외에

및 <anyAttribute> 스키마 문서의 스키마 별 요소 정보 항목은 네임 스페이스와 notNamespace 특성이 모두 존재하지 않아야합니다.

(2) 소스 스키마 문서로부터 생성 된 스키마 요소 모델에서의 제약의 관점에서 표현된다스키마 컴포넌트 제약. 콘텐츠 모델의 두 요소 입자가 같은 이름을 갖고 있다면 같은 유형을 가져야한다는 것을 나타내는 "요소 선언 일관성"제약 (§3.8.6.3)이 그 예입니다.

다른 스키마 프로세서는 스키마 유효성을 검사하는 다양한 방법을 제공합니다. 그냥

Validate -xsd:my-schema.xsd -t 

이 (스키마없이 원본 문서 공급) 및 스키마에 오류가 있는지 당신을 말할 것이다 할 수있는 .NET에 색슨과 함께 예를 들어.