JSON과 XML에 대한 심층 분석, 3부: XML과 JSON의 미래

게시 됨: 2022-03-11
관련 항목: JSON과 XML에 대한 심층 분석, 2부: 둘 다의 장단점

이 기사의 2부에서는 데이터 교환으로서의 JSON을 자세히 살펴보고 단순한 애플리케이션과 복잡한 애플리케이션에 대한 JSON의 장단점을 평가했습니다. JSON은 가장 간결하고 사람이 읽을 수 있는 가장 간결한 형식으로 눈에 띄지만, 기본 단순성은 복잡한 사용 사례에 사용될 때 의도하지 않은 의미를 초래할 수 있습니다. JSON을 데이터 교환으로 사용하면 개발자는 JSON 자체에서 누락된 기능을 스스로 구현해야 하므로 격차를 충족시키려는 결합된 비표준 솔루션이 생깁니다. 오류 없는 작동을 주장하는 엔터프라이즈 솔루션의 경우 JSON을 사용하면 시스템의 코드 품질, 안정성 및 미래의 알 수 없는 것에 대한 탄력성을 저해할 수 있는 원하지 않는 패턴이 발생할 수 있습니다. XML은 애플리케이션이 이러한 위험을 완화하는 데 도움이 되는 기능을 제공합니까? JSON으로 동일한 기능을 수행할 수 있습니까? 데이터 교환으로 XML을 자세히 살펴보면 소프트웨어 위험을 줄이는 데 있어 XML의 강점이 드러나고 개발자가 응용 프로그램의 품질을 개선하는 데 도움이 될 수 있는 패턴을 더 잘 이해할 수 있습니다.

이 기사의 3부에서는 다음을 수행합니다.

  1. XML을 데이터 교환으로 탐색하고 복잡한 요구 사항을 지원하는 데 있어 XML의 강점을 평가합니다.
  2. JSON의 미래에 대해 논의하고 XML의 강점을 JSON으로 가져와 개발자가 버그와 미래의 알려지지 않은 사항에 대해 더 안정적이고 내성이 강한 소프트웨어를 구축할 수 있도록 하는 솔루션을 탐색하십시오.
관련 항목: JSON 대 XML에 대한 심층 분석, 1부: 각 표준의 역사

XML은 JSON에 대한 복잡하고 장황한 대안으로 쉽게 레이블이 지정됩니다. 웹 표준에 대한 인기 있는 참고 자료인 w3schools.com 웹 사이트는 "JSON이 XML보다 나은 이유" 1 라는 주제에 대해 단 58단어만 제공합니다. XML이 단순한 데이터 교환 이상의 것을 제공하기 때문에 JSON 대 XML에 대한 이러한 단순한 평가는 오해의 소지가 있습니다. 사실 XML은 데이터 교환 만을 위해 설계된 것이 아니라 모든 응용 프로그램에 대한 사용자 지정 마크업 언어를 지정하기 위한 언어로 설계되었습니다. 엄격한 의미로 XML은 XML 하위 언어의 XML 문서 데이터 무결성을 주장하는 표준을 정의했습니다. 많은 개발자들이 "XML이 실패하고 JSON으로 대체되었다"고 생각하지만 이는 사실과 다릅니다. 원래 XML은 모든 데이터 상호 운용성 문제에 사용되는 것으로 계획되었으며 오늘날까지 "정보 표현 및 교환을 위해 세계에서 가장 널리 사용되는 형식"으로 남아 있습니다. 2

JSON은 간단하고 XML은 강력합니다

이 기사의 2부에서는 CDC(소비자 주도 계약), 프로토콜 진화 및 메시지 유효성 검사와 관련된 데이터 교환을 살펴보았습니다. 데이터 교환으로 JSON을 사용하는 우리의 예인 유럽 은행은 소매업체와 데이터 교환을 위한 위험 완화 솔루션을 제공해야 하는 과제를 안고 있었습니다. 은행은 낮은 결합, 높은 캡슐화 및 미래의 미지의 것에 대한 높은 탄력성을 가져오는 소프트웨어 패턴을 원했습니다. 그러나 JSON을 데이터 교환으로 사용하면 은행에 반대의 결과가 나타나는 패턴이 제공되었습니다.

European Bank의 예를 다시 살펴보고 데이터 교환 형식인 JSON을 XML로 교체해 보겠습니다. 다음 XML 메시지는 SWIFT, IBAN 및 ACH와 같은 각 계정 식별자 유형에 대한 JSON 메시지에 해당합니다.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

원시 바이트 수 효율성의 즉각적인 손실에도 불구하고 XML은 데이터 교환을 둘러싼 더 넓은 범위를 지원하여 자세한 정보를 정당화합니다. JSON으로 데이터를 인코딩함으로써 우리는 데이터 교환의 즉각적인 요구 사항을 해결할 수 있었지만 여러 메시지 변형 또는 유효성 검사를 지원하지 못했습니다. 소비자 주도 계약을 둘러싼 범위를 다루기 위해 개발자는 메시지 형식, 내용 및 처리를 위한 기능적 구현 간의 논리적 결합을 초래하는 사용자 지정 코드를 구현해야 합니다. 또는 개발자는 더 높은 요구 사항을 충족하기 위해 라이브러리 및 프레임워크 컬렉션의 퍼즐을 함께 엮을 수 있습니다. 두 가지 접근 방식 모두 애플리케이션에 직접 결합되는 데이터 교환 위에 계층의 양파를 생성합니다. 그러나 데이터를 XML로 인코딩하면 결합 없이 요구 사항의 많은 이동을 해결할 수 있습니다.

동등한 XML 메시지는 XML 표준의 두 가지 특정 기능인 네임스페이스와 인스턴스 유형을 활용합니다. xmlns="urn:bank:message" 속성은 메시지의 네임스페이스를 지정하고 "xsi:type" 속성은 해당 인스턴스 유형을 "swift" , "iban" 또는 "ach" 로 지정합니다. 이 두 속성은 메시지 프로세서가 메시지 유형을 식별하고 유효성 검사 규칙을 정의하는 스키마를 역참조할 수 있도록 하는 XML 표준입니다.

XML 스키마는 JSON과 XML 간의 주요 차별화 요소를 나타냅니다. 스키마를 사용하여 개발자는 메시지 형식의 규범적 정의를 응용 프로그램과 별개의 매체에 캡슐화하고 XML 프로세서에 의해 시행되는 유효성 검사 규칙을 제공하는 값 제약 조건을 정의할 수 있습니다. 유형 설명자 및 값 제약 조건이 포함된 European Bank( namespace: xmlns="urn:bank:message" 포함)에 대한 예제 스키마는 다음 XSD(XML 스키마 문서)입니다.

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

이 XML 스키마는 2부의 isValid(message) 함수와 논리적으로 동일합니다. 처음에는 이 XML 스키마가 isValid(message) 보다 훨씬 더 장황합니다. 그러나 둘 사이의 근본적인 차이점은 isValid(message) 는 응용 프로그램에 연결되고 XML 스키마는 연결되지 않는다는 것입니다. XML 스키마는 XML 문서에 대한 제약 조건을 표현하기 위한 언어이며 널리 사용되는 여러 스키마 언어가 있으며 그 중 주요 언어는 DTD(문서 유형 정의), Relax-NG, Schematron 및 W3C XML 스키마 정의(XSD)입니다. ). 3 European Bank의 경우 XML 스키마는 결합 없이 상위 계층 요구 사항에 대한 위험 감소 솔루션을 제공합니다.

XML 스키마는 소프트웨어 위험을 낮춥니다. XML을 사용하면 메시지 유효성 검사 규칙이 응용 프로그램과 분리되어 연결되지 않는 스키마 언어로 표현됩니다. XML 스키마가 시스템에서 완전히 분리되기 때문에 메시지 형식의 논리적 의미와 처리를 위한 기능적 구현이 분리됩니다. XML 스키마는 메시지 유효성 검사, 가변성, 버전 관리 등의 컨텍스트를 단독으로 담당하는 캡슐화된 계층을 European Bank에 제공합니다.

XML 스키마는 소비자 주도 계약의 규범적 정의를 나타냅니다. 유럽 ​​은행의 경우 이는 $\xi_0$를 0에 가깝게 줄이기 위한 위험 완화 접근 방식을 제공합니다. 스키마는 은행과 소매업체에서 분리되므로 양 당사자는 이를 사용하여 계약을 검증하고 시행할 수 있습니다.

alt_text
소비자 주도 계약은 XML 스키마에 지정되어 각 당사자가 실행할 수 있는 시행 규칙의 규범적 정의를 제공합니다. XSD는 응용 프로그램과 분리되어 있으므로 프로토콜의 각 참가자와 공유할 수 있습니다.

XML 스키마가 장황한 이유는 무엇입니까?

XML 스키마 사양은 개발자가 XML 문서의 모든 구성 요소를 정의하고 제한하는 데 사용되는 구조적 및 논리적 패턴을 구현하는 언어를 제공합니다. XML 스키마를 사용하여 개발자는 XML 문서의 각 구조적 및 논리적 부분에 더 깊은 의미를 포함할 수 있습니다. 예를 들어 XML 스키마는 다음을 허용합니다.

  1. 구성 문자열에 대한 정규식 제약 조건 정의,
  2. 구성 숫자의 범위 및 형식 정의,
  3. 필수 및 선택적 구성 요소 및 속성의 정의,
  4. 문서의 핵심 및 참조 요구 사항 정의 등.

XML 스키마를 사용하면 시스템은 일반 XML 유효성 검사기에 의존하여 각 입력 메시지의 유효성을 주장할 수 있으며 본질적으로 "오류 공간" $\xi_0$을 0에 가깝게 줄이고 비즈니스 로직을 잘못된 입력으로부터 자동으로 격리할 수 있습니다.

미래 발전의 위험

시스템은 XML 사양의 고유한 기능을 활용하여 향후 개발의 소프트웨어 위험을 줄일 수 있습니다. XML 스키마 형태의 규범적 계약에 동의함으로써 시스템은 교환될 모든 객체와 속성(XML의 경우 요소 및 속성)에 대한 규칙과 제약 조건을 정의합니다. 그 후 시스템은 더 넓은 범위의 XML 사양을 활용하여 메시지 가변성, 프로토콜 버전 관리 및 콘텐츠 유효성 검사를 처리할 수 있습니다. 예를 들어, XML 네임스페이스는 다음을 수행하는 데 필요한 정보가 포함된 XML 메시지를 제공합니다.

  1. 메시지 버전을 식별합니다.
  2. 규범적 계약 스키마를 역참조합니다.
  3. 문서의 정확성을 확인합니다.

XML 스키마가 제공하는 광범위한 기능과 데이터 교환을 둘러싼 복잡한 요구 사항의 대부분은 XML 자체로 해결할 수 있습니다. 이것이 바로 Dr. Charles Goldfarb가 "[XML은] 컴퓨팅의 성배"라고 말할 때 언급한 것입니다. 4

XML 스키마는 응용 프로그램이 오류에 탄력적이며 향후 변경 사항에 유연하게 대처할 수 있도록 도와줍니다.

XML은 XML 문서의 처리 및 유효성 검사를 지원하기 위해 모든 플랫폼에서 사용할 수 있는 수많은 라이브러리가 있는 널리 인정되고 철저하게 검증된 사양입니다. XML을 데이터 교환 형식으로 사용하여 개발자는 즉각적인 요구 사항은 물론 소비자 중심 계약, 메시지 가변성, 프로토콜 버전 관리 및 콘텐츠 유효성 검사와 관련된 요구 사항을 해결할 수 있습니다. XML을 사용하면 개발자가 복잡한 요구 사항과 더 중요하게는 미래에 알려지지 않은 위험을 헤지할 수 있습니다.

XML은 데이터 교환 그 이상이며 JSON보다 훨씬 더 큰 문제를 해결하는 데 사용할 수 있습니다. 이러한 관점에서 볼 때 XML의 범위는 양파의 더 많은 부분을 포함하며, 이에 따라 양파의 여러 레이어가 XML 자체의 범위에 포함됩니다.

alt_text
ㅏ. 데이터 교환으로서의 XML.
비. XML 스키마로 캡슐화된 메시지 유효성 검사. 이 코드는 애플리케이션에서 분리 됩니다.
씨. 캡슐화되지 않은 메시지 유효성 검사. 이 코드는 비즈니스 계층과 혼합되어 있습니다.
디. 응용 프로그램.

응용 프로그램에 가장 적합한 데이터 교환 형식을 선택할 때 우리가 관심을 두는 부분은 양파의 중심입니까, 아니면 양파 전체입니까?

JSON과 XML의 근본적인 차이점

XML은 데이터 교환 이상의 것을 제공하며 JSON보다 훨씬 더 큰 문제를 해결하는 데 사용할 수 있습니다. 데이터 교환을 둘러싼 복잡한 요구 사항의 범위는 XML에 의해 수용되어 시스템이 응용 프로그램에서 분리된 표준을 준수하는 라이브러리와 프레임워크를 활용할 수 있습니다.

XML은 설계상 복잡한 요구 사항의 범위를 다루는 사양이며 W3C에서 정의하고 모든 관련 소프트웨어 공급업체 및 언어 플랫폼에서 지원하는 표준입니다. XML을 데이터 교환으로 사용함으로써 애플리케이션은 소프트웨어 위험의 체계적인 감소로부터 자동으로 이익을 얻습니다.

JSON의 미래

JSON은 분명히 여기에 있습니다. 오늘날 가장 널리 사용되는 개발 플랫폼인 JavaScript와 함께 JSON은 가장 눈에 띄는 데이터 교환 형식이 되었습니다. 복잡성이 낮은 소규모 프로젝트의 경우 JSON이 완벽합니다. 그러나 미래를 위해 더 크고 더 나은 응용 프로그램을 만들기 위해 노력함에 따라 소프트웨어의 일반적인 복잡성은 증가할 것입니다. XML의 강력한 기능을 예로 들어 여러 그룹에서 JSON에 대한 유사한 표준을 만들기 위해 노력했습니다.

JSON의 근본적인 결함은 문서의 논리적 구성 요소에 대한 규범적 설명에 대한 일반 표준을 제공하지 않는다는 것입니다.

JSON 스키마

2009년에 그룹은 JSON 문서에 주석을 달고 유효성을 검사하는 어휘인 JSON 스키마 5 를 시작했습니다. JSON 스키마는 JSON 의미 체계를 사용하여 JSON 문서의 구성 요소에 대한 규칙 및 제약 조건 집합을 정의하고 다양한 플랫폼의 여러 프로젝트에서 JSON 스키마 사양을 지원하는 라이브러리를 구현했습니다. 아직 공식 표준은 아니지만 JSON 스키마 프로젝트는 XML 스키마 사양과 유사한 요구 사항 범위에 대한 솔루션을 제공합니다. JSON 스키마 어휘를 사용하여 개발자는 JSON 문서의 논리적 및 구조적 규칙과 제약 조건을 정의할 수 있습니다. 그런 다음 스키마를 사용하여 애플리케이션에서 분리된 라이브러리가 있는 JSON 문서의 처리 및 유효성 검사를 지원할 수 있으므로 캡슐화되지 않은 코드를 애플리케이션에서 혼합할 필요성을 줄일 수 있습니다. JSON 스키마를 사용하면 개발자는 데이터 교환 형식으로 JSON을 선택하고 이전에는 JSON만으로는 해결할 수 없었던 복잡한 요구 사항을 위험 완화 방식으로 처리할 수 있습니다.

JSON 스키마 프로젝트는 커뮤니티의 노력으로 10년 간의 수정 후에 JSON 스키마에 대한 일반적인 사양이 되었습니다. 아직 표준은 아니지만 JSON 스키마 프로젝트의 인기는 이러한 솔루션에 대한 관심 수준을 나타냅니다. 개념적으로 JSON 스키마 사양은 XML 스키마와 유사하지만 둘을 비교하면 모델, 기능 및 의미 체계 간의 차이점이 드러납니다. 예를 들어, 언어는 JSON 값 유형의 경계를 제한하기 위해 광범위한 속성을 정의하지만 그 수많은 속성은 자기 모순적인 스키마 정의의 표현을 허용합니다.

예를 들어, 다음 발췌문은 "number" , "street_name" 및 "street_type" 세 가지 속성을 포함하는 "object" 유형을 정의합니다.

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

"object" 유형의 정의는 추가 제약 조건을 허용하며 그 중 하나는 "minProperties" 입니다. 위의 "object" 유형 정의를 "minProperties": "4" 로 수정하면 객체에 대해 3개의 속성만 명시적으로 정의되기 때문에 정의가 무의미해집니다.

JSON 스키마에는 상당히 크고 다양한 제약 조건 속성이 있으며, 그 중 많은 속성이 JSON 문서를 효과적으로 제한하는 데 필수적이며 그 중 많은 속성이 서로 겹칩니다. 의미가 겹치는 제약 조건 속성을 사용하여 JSON 스키마 어휘는 두 가지 문제 패밀리를 나타냅니다.

  1. 광범위한 어휘와 의미 체계의 독특하거나 관습에 얽매이지 않는 뉘앙스로 인해 개발자의 더 높은 학습 곡선이 필요합니다.
  2. 유효성 검사 라이브러리를 구현하는 것이 더 어렵기 때문에 회색 영역을 다르게 구현하는 솔루션으로 이어지며 구현이 일관되지 않습니다.

XML 스키마 언어 자체는 모순되는 정의의 표현을 완전히 허용하지 않지만 훨씬 적고 제한적입니다. 사실, XML 스키마 사양은 개발자와 사양을 구현하는 라이브러리 모두의 사용 용이성에 세심한 주의를 기울여 개발되었습니다. 또한 JSON 스키마 프로젝트는 스키마 언어의 사양만 정의하지만 이 사양을 구현하는 커뮤니티 프로젝트가 많이 있습니다.

JSON 스키마 유효성 검사기 6 은 Java 플랫폼용 JSON 스키마 유효성 검사기를 구현하는 인기 있는 프로젝트입니다. 이 라이브러리를 Java 애플리케이션에 통합함으로써 애플리케이션은 교환되는 모든 JSON 문서의 적합성을 주장할 수 있습니다. JSON 스키마 사양의 다른 구현은 다양한 플랫폼에서 사용할 수 있습니다.

유럽 ​​은행의 경우 JSON 스키마를 사용하여 계정 식별자가 있는 JSON 메시지에 대한 스키마를 구현해 보겠습니다.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

이 JSON 스키마는 "swift" , "iban" 및 "ach" 의 3가지 객체 유형을 정의합니다. 계정 정보가 유효하지 않다고 주장하는 정규식 패턴을 지정하고 "ach" 유형에 대한 필수 속성으로 "routing" 에 추가하여 각 유형에 대한 필수 속성으로 "type" 및 "code" 를 선언합니다. 이 JSON 스키마를 사용하여 European Bank는 JSON 입력의 유효성을 검사하여 메시지 콘텐츠가 모든 상호 작용에 대해 정확하다고 주장할 수 있습니다.

JSON 스키마는 XML의 많은 기능을 JSON에 제공하지만 아직 진행 중인 작업입니다. 소프트웨어 위험을 헤지하는 데 사용할 수 있는 훌륭한 솔루션이지만 JSON 스키마 사양은 완벽하지 않습니다. 언어의 비공식적 진화로 인해 언어는 틀림없이 중요한 기능을 생략하고 혼란스럽고 비관습적인 구조적, 논리적 표현 패턴을 포함하는 방향으로 진화했습니다. 예를 들어 스키마 언어에는 추상 유형을 정의할 수 있는 기능이 없기 때문에 개발자가 복잡한 해결 방법을 구현하여 관련 소프트웨어 위험을 초래할 수 있습니다. 7

JSON 스키마 프로젝트는 JSON용 스키마 언어의 이면에 있는 개념에 대한 귀중한 공헌을 가져왔습니다. 의미 체계의 명확성 부족에도 불구하고 JSON 스키마 언어는 XML의 많은 기능을 JSON으로 가져오는 다용도 솔루션입니다.

JSON 스키마 사양에 대한 자세한 내용은 JSON 스키마 이해를 참조하세요.

JSONx

2014년에 또 다른 그룹은 XML을 직접 활용하여 JSON에 대해 동등하게 강력한 솔루션을 제공하는 JSONx 프로젝트를 시작했습니다. JSONx 프로젝트는 기업을 위해 특별히 생성되었으며 XML 스키마 사양에 가깝게 모델링된 JSD(JSON 스키마 정의) 언어를 정의합니다. XML 스키마를 모델로 사용하여 JSD는 XML 스키마 정의 언어와 매우 유사한 구조적 및 논리적 패턴을 정의합니다.

유럽 ​​은행 예의 경우 JSD 언어를 사용하여 계정 식별자가 있는 JSON 메시지에 대한 스키마를 구현해 보겠습니다.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

언뜻 보기에 JSD 스키마는 JSON 스키마와 표현 방식이 유사합니다. 그러나 한 가지 차이점은 JSON 스키마와 비교하여 JSD의 간결한 의미입니다. 이 예와 관련하여 JSD는 "use": "required" 속성을 지정 중인 정의에 배치하는 반면 JSON 스키마는 이 속성을 상위 개체와 연결하므로 속성 정의의 이름과 일치하는 값의 이름이 필요합니다. "use": "required" 제약 조건은 "swift" 개체의 "code" 속성에만 지정되고 "use": "required" 가 기본값이기 때문에 나머지는 생략됩니다. JSD 언어는 이러한 모든 뉘앙스를 면밀히 고려하여 설계되었으며 JSON 스키마 표현을 위한 깨끗하고 직관적인 솔루션을 제공합니다.

처음부터 JSONx 프로젝트의 구별되는 속성은 개발자에게 명확성과 유용성을 제공하는 주요 의도입니다. 이를 달성하기 위해 JSD의 강력한 기능은 JSDx로의 변환 가능성입니다. JSD 언어는 XML 파일뿐만 아니라 JSON 파일로도 표현할 수 있습니다. 두 형식 모두 일대일 번역이 가능하며 개발자에게 고급 XML 편집 도구를 사용하여 실시간으로 검증되고 오류가 없는 JSD 문서 생성을 지원하는 기능을 제공합니다.

위의 JSD 스키마는 다음 JSDx 형식으로 표현할 수 있습니다.

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

JSD의 JSDx 형식은 JSON 스키마를 정의하기 위해 명확하고 자체 검증하며 위험이 감소된 사양을 제공하기 때문에 강력합니다.

JSD 언어는 자기 모순적인 정의의 문제를 해결하도록 설계되었으며 제약 조건의 표현을 위한 표준 패턴에 의존합니다. XSD(XML 스키마 정의) 언어와 매우 유사하게 설계된 JSD 유형 선언 및 제약 조건 정의는 XML의 동등한 구조와 매우 유사합니다. JSD(x) 사양은 구조적 및 논리적 제약 조건의 정의를 위한 완전한 솔루션을 제공하며 JSD(x) 언어 자체로 표현되는 JSD(x) 언어의 규범적 정의를 제공하는 자체 설명적입니다. JSD(x) 사양에 대한 자세한 내용은 JSON 스키마 정의 언어를 참조하세요.

JSD(x) 언어 외에도 JSONx 프로젝트는 JSD(x) 프로세서 및 유효성 검사기의 참조 구현은 물론 Java 플랫폼용 클래스 바인딩 API 및 코드 생성기를 제공합니다. 바인딩 API 및 생성기를 통해 개발자는 JSD(x) 스키마를 사용하여 원하는 스키마의 객체 정의에 대한 클래스를 자동 생성할 수 있습니다. 이 클래스는 스키마를 준수하는 JSON 문서를 구문 분석하고 마샬링하는 데 사용할 수 있습니다. 생성된 클래스는 스키마와 Java 플랫폼 간에 강력한 형식의 바인딩을 제공하여 스키마에 지정된 사용법, 제약 조건 및 관계를 나타냅니다. 스키마에 대한 강력한 형식의 바인딩을 통해 응용 프로그램은 비호환성을 초래할 수 있는 향후 수정과 관련된 소프트웨어 위험을 더욱 줄입니다.

강력한 형식의 바인딩은 Java 컴파일러를 활용하여 컴파일 시간 오류와의 비호환성을 정확히 찾아내어 메시지 처리와 관련된 버그의 위험을 거의 0에 가깝게 줄입니다. 이 엔지니어링 패턴을 사용하면 개발자가 변경 사항을 구현하고 비호환성을 빠르고 자신 있게 해결할 수 있으므로 버그나 오류 사례를 찾기 위해 런타임에 의존할 필요가 없으며 특히 사용자가 버그를 직접 발견할 필요가 없습니다. 바인딩 API는 Java 주석으로 구현되어 모든 클래스를 강력한 유형의 JSD(x) 스키마에 바인딩할 수 있지만 가벼운 방식으로 사용할 수 있습니다. JSONx의 강력한 형식 바인딩 및 코드 생성 기능은 엔터프라이즈 솔루션에 대한 높은 표준을 충족하도록 특별히 설계된 JSD(x) 사양의 전체 범위를 지원합니다.

JSONx 프레임워크는 엔터프라이즈 솔루션을 위해 만들어졌으며 개발자를 위한 사용 편의성 및 편집 시 오류 검증은 물론 복잡한 시스템을 위한 높은 수준의 품질 및 유틸리티를 제공합니다.

JSD(x) 바인딩 엔진, 프로세서 및 유효성 검사기는 87%의 테스트 범위를 보고하므로 Java 개발자는 프레임워크를 자신 있게 통합하여 JSD(x) 스키마를 Java 애플리케이션에 바인딩하고 JSON 문서를 인코딩, 디코딩 및 검증할 수 있습니다. Java용 JSONx 프레임워크에 대한 자세한 내용은 Java용 JSONx 프레임워크를 참조하세요.

결론

최근 몇 년 동안 웹의 역사와 소프트웨어 동향을 자세히 살펴보면 JavaScript의 확산과 JSON의 인기 사이에 밀접한 관계가 있음을 알 수 있습니다. 많은 기사와 블로그 게시물은 JSON과 XML을 비교할 때 제한된 관점을 제공하여 독자들로 하여금 XML을 구식이라고 무시하게 만들고 많은 사람들이 소프트웨어 아키텍처, 소프트웨어의 변화에 ​​대한 탄력성, 전반적인 품질 및 소프트웨어 전체의 안정성. 각 표준의 강점과 약점에 대한 심층 평가를 통해 개발자는 프로젝트에 대해 더 나은 결정을 내릴 수 있습니다.

XML의 발명으로 이어진 HTML의 "다이버전스 재앙"처럼 데이터 교환을 위해 JSON에 의존하는 복잡한 코드베이스에서도 유사한 효과가 실현됩니다. JSON 사양은 데이터 교환을 둘러싼 즉각적인 기능을 캡슐화하지 않으므로 애플리케이션의 상위 계층에서 논리 단편화가 발생할 수 있습니다. 그러나 XML을 사용하면 개발자는 데이터 교환을 둘러싼 복잡성을 응용 프로그램의 하위 계층으로 밀어넣을 수 있으므로 응용 프로그램 수명 주기의 초기에 버그를 잡을 수 있습니다. 특히 컴파일된 언어의 경우 바인딩 프레임워크와 결합하여 XML 바인딩에 의존하는 아키텍처는 데이터 관련 오류 가능성을 0에 가깝게 줄일 수 있습니다. 기업의 경우 XML을 "컴퓨팅의 성배"로 만드는 것은 소프트웨어 위험을 체계적으로 줄이는 강력한 기능입니다.

JSON은 계속 존재하며 여러 프로젝트에서 강력한 XML 기능을 JSON에 제공하기 위한 추진력을 얻고 있습니다. JSON 스키마 프로젝트는 JSON 문서를 설명하고 제한하기 위해 광범위한 속성과 선언적 패턴을 지원하도록 유기적으로 성장한 커뮤니티 개발 스키마 사양을 제공합니다. JSONx 프로젝트는 XML 스키마 정의 언어와 매우 유사하게 설계된 엔터프라이즈급 스키마 언어를 제공하며 JSON 스키마 문서 사양을 위해 JSON 및 XML 형식을 모두 제공합니다. 이러한 사양 및 프레임워크를 통해 개발자는 소비자 중심 계약, 프로토콜 버전 관리, 콘텐츠 유효성 검사 등과 같은 데이터 교환을 둘러싼 상위 계층 요구 사항과 관련된 소프트웨어 위험을 줄일 수 있습니다.

XML의 고급 기능은 마크업 언어와 관련된 소프트웨어 위험을 완화하도록 설계되었습니다. JSON의 사용 사례도 다르지 않으며 스키마 언어는 데이터 교환을 둘러싼 광범위한 소프트웨어 위험을 체계적으로 헤지하기 위해 오랜 시간 테스트되고 입증된 솔루션입니다.

참고문헌

1. JSON 대 XML(w3schools.com, 2016년 12월)

2. XML을 통한 세계적인 성공(W3C, 2018년 7월)

3. W3C - XML ​​스키마란 무엇입니까? (W3C, 2009년 10월)

4. 인터넷: 역사 백과사전. 연대기, 3권, p. 130(ABC-CLIO, 2005)

5. JSON 스키마(2008년 7월)

6. JSON 스키마 유효성 검사기(GitHub)

7. JsonSchema 및 SubClassing(Horne, 2016년 3월)