XML 스키마

이 문서에는 여러 가지 문제가 있습니다.개선을 돕거나 토크 페이지에서 이러한 문제에 대해 논의해 주십시오.(이러한 템플릿메시지를 삭제하는 방법과 타이밍에 대해 설명합니다) 이 기사에는 독창적인 연구가 포함되어 있을 가능성이 있다. 클레임을 확인하고 인라인 인용을 추가하여 개선해 주십시오. 독창적인 연구로만 구성된 문장은 삭제해야 합니다. (2015년 3월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인) 이 글은 검증을 위해 추가 인용문이 필요합니다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : 'XML 스키마'– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2015년 3월) (이 템플릿 메시지 삭제 방법 및 삭제 시기 확인) (이 템플릿메시지를 삭제하는 방법과 타이밍을 확인합니다)

XML 스키마는 XML 문서 유형에 대한 설명으로, 일반적으로 XML 자체에 의해 부과되는 기본 구문적 제약 조건 이상에서 해당 유형의 문서 구조와 내용에 대한 제약 조건으로 표현됩니다.이러한 제약은 일반적으로 요소의 순서를 관리하는 문법 규칙, 콘텐츠가 충족해야 하는 부울 술어, 요소 및 속성의 내용을 지배하는 데이터 유형, 고유성 및 참조 무결성 제약과 같은 보다 전문적인 규칙의 조합을 사용하여 표현됩니다.

XML 스키마를 표현하기 위해 특별히 개발된 언어가 있습니다.XML 사양에 고유한 DTD(Document Type Definition) 언어는 상대적으로 기능이 제한적이지만 XML에서 스키마 표현 외에 다른 용도로도 사용됩니다.널리 사용되는 표현력이 풍부한 XML 스키마 언어로는 XML 스키마(대문자 S)와 REXE NG가 있습니다.

XML 문서를 스키마에 연결하는 메커니즘은 스키마 언어에 따라 다릅니다.연관성은 XML 문서 자체의 마크업 또는 외부 수단을 통해 달성될 수 있습니다.

XML 스키마 정의는 일반적으로 XSD라고 불립니다.

확인

XML 문서가 스키마를 준수하는지 확인하는 프로세스를 검증이라고 하며, XML의 핵심 개념인 구문적 형식과는 별개입니다.모든 XML 문서는 올바른 형식이어야 하지만 XML 파서가 "검증"을 수행하지 않는 한 문서가 유효할 필요는 없습니다. 이 경우 문서가 연관된 스키마와 호환되는지 여부도 검사됩니다.DTD 검증 파서가 가장 일반적이지만 XML 스키마 또는 REXE NG도 지원합니다.

스키마에 대한 인스턴스 문서 검증은 XML 구문 분석과 개념적으로 분리된 작업으로 간주할 수 있습니다.그러나 실제로는 많은 스키마 검증자가 XML 파서와 통합되어 있습니다.

언어들

XML 스키마를 지정하는 데 사용할 수 있는 언어는 여러 가지가 있습니다.언어마다 장단점이 있습니다.

스키마 언어의 주요 목적은 XML 문서의 구조를 지정하는 것입니다.즉, 어떤 요소가 어떤 다른 요소에 존재할 수 있는지, 어떤 속성을 특정 요소에 가질 수 있는지 등입니다.스키마는 언어의 문법과 유사합니다; 스키마는 언어의 어휘가 무엇이고 유효한 "문장"이 무엇인지 정의합니다.

이력 및 현재의 XML 스키마 언어가 있습니다.

주요 언어(ISO 19757의 승인 언어 참조)는 다음과 같다.

사용 가능한 스키마 언어는 여러 가지가 있지만 주요 3개 언어는 Document Type Definitions, W3C XML Schema 및 REXENG입니다.각 언어마다 장단점이 있습니다.

문서 유형 정의

도구 지원

DTD는 XML에서 가장 널리 지원되는 스키마 언어입니다. DTD는 XML에서 가장 먼저 정의된 스키마 언어 중 하나이기 때문에 XML이 네임스페이스를 지원하기도 전에 널리 지원됩니다.내부 DTD는 XML 프로세서에서 지원되는 경우가 많지만 외부 DTD는 거의 지원되지 않지만 약간만 지원됩니다.대부분의 대형 XML 파서(복수의 XML 기술을 지원하는 것)는 DTD도 지원합니다.

W3C XML 스키마

DTD에 대한 이점

XSD에서 사용할 수 있는 DTD에는 없는 기능은 다음과 같습니다.

• 요소 및 속성의 이름은 네임스페이스 인식
• 요소 및 속성의 텍스트 내용에 대해 구속조건("단순 유형")을 정의할 수 있습니다. 예를 들어, 구속조건이 숫자이거나 날짜를 포함하도록 지정할 수 있습니다.단순한 유형의 광범위한 레퍼토리가 표준으로 제공되며, 이들로부터 예를 들어 값의 범위를 지정하거나 정규식을 지정하거나 허용되는 값을 열거함으로써 추가 사용자 정의 유형을 도출할 수 있다.
• 고유성 제약 조건 및 참조 무결성을 정의하는 기능은 더 강력합니다. DTD의 ID 및 IDREF 제약 조건과 달리 문서의 모든 부분에 범위를 지정할 수 있으며, 데이터 유형, 요소 및 속성 내용에 적용할 수 있으며, 여러 부분으로 나눌 수 있습니다(예: 성과 이름의 조합이 고유해야 함).ue)
• DTD의 파라미터 엔티티를 사용하여 처리되어 온 많은 요건에는 XSD가 명시적으로 지원되고 있습니다.예를 들어 단일 이름('블록'이나 '인라인' 등)이 요소의 전체 클래스를 참조할 수 있는 대체 그룹, 동일한 콘텐츠 모델을 공유(또는 제한 또는 확장자에 의해 조정됨)할 수 있는 복잡한 유형 등이 있습니다.y개의 다중 요소 및 모형 그룹 및 속성 그룹을 사용하여 구성요소 모형의 공통 부분을 한 곳에서 정의하고 재사용할 수 있습니다.
• XSD 1.1은 요소 콘텐츠의 제약으로 (XPath 식을 사용하여) 임의 어사션을 정의하는 기능을 추가합니다.

XSD 스키마는 일반적으로 XML 문서로 작성되므로 익숙한 편집 및 변환 도구를 사용할 수 있습니다.

XSD를 사용하면 검증뿐만 아니라 XML 인스턴스에 유형 정보(PSVI)를 주석을 달 수 있습니다.PSVI(Post-Schema-Validation Infoset)는 응용 프로그램에서 XML 인스턴스를 보다 쉽게 조작할 수 있도록 설계되었습니다.이는 XSD 정의 유형을 Java("데이터 바인딩")와 같은 프로그래밍 언어로 된 유형에 매핑하거나 XSLT 및 XQuery와 같은 XML 처리 언어의 유형 시스템("schema-agness")을 강화함으로써 가능합니다.

RELEX NG와의 공통점

RELEX NG 및 W3C XML 스키마에서는 유사한 특정 메커니즘이 허용됩니다.두 언어 모두 스키마를 여러 파일로 분할하는 등 어느 정도의 모듈화를 허용합니다.둘 다 XML 언어로 정의되거나^{[clarification needed]} 정의될 수 있습니다.

RELEX NG에 대한 이점

RELEX NG에는 PSVI와 유사한 기능이 없습니다.W3C XML Schema와 달리 RELEX NG는 검증과 증강(타입 정보와 기본값 추가)이 분리되도록 설계되었습니다.

W3C XML Schema에는 XML 문서에 스키마를 부가하는 정식 메커니즘이 있으며 RELEX NG는 보안 및 상호 운용성을 위해 이러한 메커니즘을 의도적으로 회피합니다.

RELEX NG에는 기본 속성 데이터를 요소의 속성 목록(XML 정보 세트 변경 등)에 적용할 수 없지만 W3C XML Schema에는 적용할 수 있습니다.다시 말씀드리지만, 이 설계는 의도적인 것으로 ^[8]검증과 증강을 분리하기 위한 것입니다.

W3C XML Schema에는 풍부한 '심플 타입' 시스템이 내장되어 있습니다(xs:number, xs:date 등, 커스텀 타입의 파생).또, REX NG는, 독자적인 확장이 아니고, REX NG로부터 독자적으로 개발된 타입 라이브러리를 사용하는 것을 목적으로 하고 있기 때문에, 지극히 심플한 것입니다.이것은 일부 사람들에게 단점으로 여겨진다.실제로 RELACE NG 스키마에서는 W3C XML 스키마의 사전 정의된 "단순한 유형" 및 "제한"(패턴, max Length 등)을 사용하는 것이 일반적입니다.

W3C XML 스키마에서는 패턴의 특정 횟수 또는 반복 범위를 표현할 수 있지만 RELACE NG(<oneOrMore> 또는 <zeroOrMore>)에서는 실질적으로 지정할 수 없습니다.

단점들

W3C XML 스키마는 복잡하고 배우기 어렵습니다.다만, 부분적으로는 검증 이상의 것을 시도하고 있기 때문입니다(PSVI 참조).

XML로 기술하는 것도 장점이지만 어떤 면에서는 단점이 되기도 합니다.특히 W3C XML Schema 언어는 매우 상세하지만 DTD는 간결하고 비교적 쉽게 편집할 수 있습니다.

마찬가지로 문서를 스키마와 관련짓는 WXS의 공식 메커니즘도 잠재적인 보안 문제를 일으킬 수 있습니다.임의의 온라인 로케이션에 URI를 추종하는 WXS 검증자의 경우 ^[9]스트림의 반대편에서 악의적인 것을 읽을 가능성이 있습니다.

W3C XML 스키마는 문서에 데이터 요소를 제공하는 대부분의 DTD 기능을 구현하지 않습니다.

요소에 기본 속성을 추가하는 W3C XML Schema의 기능은 장점이지만 어떤 면에서는 단점도 있습니다.즉, 문서가 해당 스키마에 대해 검증하더라도 스키마가 없으면 XML 파일을 사용할 수 없습니다.실제로 이러한 XML 문서의 모든 사용자는 W3C XML Schema 사양도 구현해야 합니다.따라서 미니멀리스트 또는 오래된 XML 파서는 제외됩니다.또한 프로세서가 잠재적으로 두 번째 XML 파일(스키마)을 다운로드하여 처리해야 하므로 문서 처리 속도가 느려질 수 있습니다. 그러나 일반적으로 스키마는 캐시되므로 비용은 처음 사용할 때만 발생합니다.

도구 지원

WXS 지원은 다수의 대규모 XML 해석 패키지에 포함되어 있습니다.Xerces 와.NET Framework의 Base Class Library는 모두 WXS 검증을 지원합니다.

릴렉스 NG

RELEX NG는 W3C XML Schema가 DTD에 비해 제공하는 대부분의 이점을 제공합니다.

W3C XML 스키마에 대한 이점

RELEX NG의 언어는 XML로 기술할 수 있지만, DTD에 훨씬 가깝지만 지정 능력이 뛰어난 동등한 형식을 가지고 있습니다.이 형식을 콤팩트 구문이라고 합니다.툴은 기능의 손실이나 코멘트 없이 이들 폼을 쉽게 변환할 수 있습니다.RELEX NG XML 요소 사이에 지정된 임의의 요소도 콤팩트 형식으로 변환할 수 있습니다.

RELEX NG는 주문되지 않은 콘텐츠를 매우 강력하게 지원합니다.즉, 일련의 패턴이 임의의 순서로 표시되는 것을 스키마가 기술할 수 있습니다.

RELEX NG는 비결정론적 콘텐츠 모델도 허용합니다.즉, RELEX NG를 사용하면 다음과 같은 시퀀스를 지정할 수 있습니다.

<제로오어>   <참조: 이름='홀수' />   <참조: 이름="짝수' /> </zeroORMore> <옵션>   <참조: 이름='홀수' /> </옵션> 

검증자가 "홀수" 패턴과 일치하는 것을 발견하면 이것이 옵션의 마지막 "홀수" 참조인지 아니면 단순히 제로 OrMore 시퀀스 중 하나인지 데이터를 미리 보지 않고 알 수 없습니다.RELEX NG는 이러한 종류의 사양을 허용합니다.W3C XML 스키마에서는 모든 시퀀스가 완전히 결정되어야 합니다.따라서 위와 같은 메커니즘은 다른 방법으로 지정하거나 모두 생략해야 합니다.

RELEX NG를 사용하면 속성을 콘텐츠모델의 요소로 취급할 수 있습니다.특히, 이는 다음을 제공할 수 있음을 의미합니다.

<time name="some_name"> <choice name="has_name"> <value> </calue> </calue name="has_name"> </calue> true </calue> </calue> </calue> </calue> </calue> </>

이 블록은 요소 "some_element"에 "has_name"이라는 속성이 있어야 함을 나타냅니다.이 속성은 true 또는 false만 값으로 사용할 수 있으며 true인 경우 요소의 첫 번째 자식 요소는 텍스트를 저장하는 "name"이어야 합니다."name"이 첫 번째 요소가 될 필요가 없는 경우, 선택은 다른 요소와 함께 "interleave" 요소로 포장될 수 있습니다.RELEX NG 속성의 사양 순서는 의미가 없기 때문에 이 블록이 요소 정의의 첫 번째 블록일 필요는 없습니다.

W3C XML 스키마는 속성의 내용과 하위 요소 간의 종속성을 지정할 수 없습니다.

RELEX NG의 사양에는 2종류의 내장 타입(문자열과 토큰)만 기재되어 있습니다만, 보다 많은 것을 정의할 수 있습니다.이론적으로는 특정 목록이 없기 때문에 프로세서는 매우 문제 영역에 고유한 데이터 유형을 지원할 수 있습니다.

대부분의 RELEX NG 스키마는 알고리즘으로 W3C XML 스키마 및 DTD로 변환할 수 있습니다(상기와 같이 이들 언어에서 지원되지 않는 RELEX NG 기능을 사용하는 경우는 제외).그 반대는 사실이 아니다.따라서 RELEX NG는 스키마의 표준 버전으로 사용할 수 있으며, 사용자는 RELEX NG를 지원하지 않는 툴의 경우 다른 형태로 변환할 수 있습니다.

단점들

RELEX NG의 단점은 대부분 RELEX NG에 비해 W3C XML Schema의 장점에 대해 설명합니다.

RELEX NG의 사용자 정의 데이터 유형 지원 기능은 유용하지만 사용자가 신뢰할 수 있는 데이터 유형은 두 개뿐이라는 단점이 있습니다.이는 이론적으로 여러 검증자에 걸쳐 RELEX NG 스키마를 사용하는 경우 해당 검증자에게 이러한 사용자 정의 데이터 유형을 제공하거나 두 가지 기본 유형만 사용해야 한다는 것을 의미합니다.그러나 실제로는 대부분의 RELEX NG 프로세서는 W3C XML 스키마세트의 데이터 유형을 지원합니다.

스키마트론

Schematron은 상당히 특이한 스키마 언어입니다.메인 3가지와 달리 XML 파일의 구문을 XPath 기반 규칙 목록으로 정의합니다.문서가 이러한 규칙을 통과하면 해당 문서는 유효합니다.

이점

규칙에 근거한 특성 때문에 Schematron의 특이성은 매우 강하다.요소의 내용을 형제 중 한 명이 제어하도록 요구할 수 있습니다.또, 루트 요소에 특정의 어트리뷰트가 설정되어 있는 것을 요구하거나 요구할 수도 있습니다.또한 여러 XML 파일 간에 필요한 관계를 지정할 수도 있습니다.

단점들

Schematron은 관계형 구문을 잘하지만 문서의 기본 구조, 즉 어떤 요소가 어디로 갈 수 있는지 지정하는 기능은 매우 상세한 스키마를 낳습니다.

이 문제를 해결하는 일반적인 방법은 Schematron을 RELEX NG 또는 W3C XML Schema와 결합하는 것입니다.두 언어 모두 이 결합 형식을 지원하는 여러 스키마 프로세서가 있습니다.이를 통해 Schematron 규칙은 W3C XML Schema 또는 REXE NG에 의해 정의된 구조에 대한 추가 제약을 지정할 수 있습니다.

도구 지원

Schematron의 참조 구현은 실제로 Schematron 문서를 XML 파일을 검증하는 XSLT로 변환하는 XSLT 변환입니다.이와 같이 Schematron의 잠재적인 툴 세트는 XSLT 프로세서이지만 libxml2는 XSLT를 필요로 하지 않는 구현을 제공합니다.Sun Microsystems의 Java용 Multiple Schema Validator에는 Schemaron 규칙을 내장한 Relax NG 스키마를 검증할 수 있는 추가 기능이 있습니다.

네임스페이스 라우팅 언어(NRL)

이것은 엄밀히 말하면 스키마 언어가 아닙니다.유일한 목적은 발견된 요소의 네임스페이스를 기반으로 문서의 일부를 개별 스키마에 지정하는 것입니다.NRL은 XML 네임스페이스 목록과 각각에 대응하는 스키마의 경로일 뿐입니다.이것에 의해, 각 스키마는 독자적인 언어 정의만을 취급할 수 있게 됩니다.NRL 파일은 스키마 검증자를 해당 요소의 네임스페이스를 기반으로 올바른 스키마 파일로 라우팅합니다.

이 XML 형식은 스키마 언어에 구애받지 않고 모든 스키마 언어에 적용됩니다.

용어.

스키마 단어의 대문자화: 대문자화된 철자 "Schema"와 소문자 철자 사용 시기에 대해 약간의 혼동이 있습니다.소문자 형식은 일반적인 용어로 DTD, XML Schema(XSD), RELEX NG 등 모든 유형의 스키마를 나타낼 수 있습니다.문장의 선두에 표시되는 경우를 제외하고 항상 소문자를 사용해야 합니다.XML 커뮤니티에서 일반적으로 사용되는 "Schema"(대문자) 형식은 항상 W3C XML 스키마를 나타냅니다.

스키마 작성 선택지

스키마 정의의 초점은 문서의 구조와 일부 의미에 있습니다.그러나 스키마 디자인은 데이터베이스, 컴퓨터 프로그램 및 기타 공식 구조의 설계와 마찬가지로 스타일, 규칙 및 가독성에 대한 많은 고려사항을 수반합니다.스키마 설계 문제에 대한 광범위한 논의는 (예를 들어) Maler(1995)^[10]와 DeRose(1997)^[11]에서 확인할 수 있습니다.

일관성.

한 가지 분명한 고려사항은 태그와 속성명은 일관된 규칙을 사용해야 한다는 것입니다.예를 들어, 일부 요소 이름이 camelCase이고 다른 요소 이름이 밑줄을 사용하여 이름 또는 기타 규칙을 구분하는 스키마를 작성하는 것은 드문 일입니다.

명확하고 니모닉한 이름

다른 정식 언어들과 마찬가지로, 이름 자체가 형식적인 의미는 없지만, 좋은 이름 선택은 이해를 도울 수 있습니다."tag37"이 아닌 적절한 태그의 이름을 "chapter"로 지정하면 독자에게 도움이 됩니다.동시에, 이것은 자연어 선택에 대한 문제를 야기한다.아일랜드 게일어 문서에 사용되는 스키마는 편집자와 독자에게 공통적인 언어가 되기 때문에 요소 및 속성 이름에 동일한 언어를 사용합니다.

태그와 속성 선택

일부 정보는 요소 또는 속성 중 하나에 쉽게 "적합"할 수 있습니다.Atribute에는 XML 내의 요소를 포함할 수 없기 때문에 이 질문은 XML에서 인식할 필요가 있는 서브구조가 더 이상 없는 컴포넌트에 대해서만 발생합니다(Atribute는 여러 IDREF 값 등 여러 토큰을 지원합니다.이는 약간의 예외로 간주할 수 있습니다).속성은 일반적으로 발생하는 요소 전체와 관련된 정보를 나타내며 하위 요소는 자체적인 새로운 범위를 도입합니다.

텍스트 내용

일부 XML 스키마(특히 다양한 종류의 문서를 나타내는 스키마)는 모든 "텍스트 내용"(대략 문서를 소리내어 읽을 경우 말하는 모든 부분)이 텍스트로 발생하고 속성은 절대 표시되지 않습니다.단, 이것이 유지되지 않는 많은 엣지 케이스가 있습니다.첫째, 원격측정, 벡터 그래픽스 작성 또는 수학 공식 등 "자연어"를 전혀 포함하지 않거나 최소한만 포함하는 XML 문서가 있습니다.둘째, 연극의 무대 방향, 고전과 대본의 구절 번호, 필사된 작품의 철자 수정 또는 정규화 등의 정보는 모두 그러한 장르의 스키마 디자이너들이 고려해야 할 해석의 문제를 제기한다.

스키마 재사용

새로운 XML 스키마를 처음부터 개발하거나 다른 XML 스키마의 일부 fragment를 재사용할 수 있습니다.모든 스키마 언어는 몇 가지 도구를 제공합니다(예:include네임스페이스에 대한 모듈화 제어) 및 실용적인 경우 재사용을 권장합니다.광범위하고 정교한 텍스트 인코딩 이니셔티브 스키마의 다양한 부분은 다른 스키마에서도 매우 다양하게 사용됩니다.

시멘틱 vs 구문^{[dubious – discuss]}

RDF 관련 언어를 제외하고 스키마 언어는 공식적으로 의미론적으로 표현되지 않고 구조 및 데이터 유형만 표현됩니다.이상적이긴 하지만 RDF 전제 조건의 포함은 매우 미흡하며 스키마 개발 프레임워크에 권장 사항이 아닙니다.

「 」를 참조해 주세요.

• data 구조
• XML 스키마 목록
• 스키마(명료화)(다른 용어의 사용)
• 구조화 정보
• XML 정보 세트
• XML 로그

언어:

• 클릭스
• 문서 구조 설명
• 문서 유형 정의
• 네임스페이스 라우팅 언어
• 네임스페이스 기반 검증 디스패치 언어
• 오아시스 캠
• 릴렉스 NG
• 스키마트론
• W3C XML 스키마

레퍼런스

• 이동원 Wesley W의 6가지 XML 스키마 언어 비교 분석Chu, ACM SIGMOD 레코드, 제29권, 제3호, 76-87쪽, 2000년 9월
• 형식언어이론을 이용한 XML 스키마 언어 분류법 (무라타 마코토, 이동원, 마니, 가와구치 고스케, ACM 번역).인터넷 테크놀로지(TOIT), 제5권, 제4호, 1-45페이지, 2005년 11월

외부 링크

• Eric van der Vlist의 XML 스키마 언어 비교 (2001)
• Sridhar Guthula, W3C Schema Experience Report, 2005년 5월 Web Services Security에서의 XML 스키마 적용
• 2009년 3월, DEVX 기사 「Taking XML Validation to the Next Level:마이클 소렌스의 'CAM 소개