XML 변호

내가 직업 생활을 시작했을 때, XML은 없는 곳이 없었다.Java JAR 파일(목록)의 메타 정보는 고유 형식을 따릅니다.그러나 자바 EE 디자이너는 XML에서 처음부터 구축했다. 모든 부품의 메타정보는 XML 형식이다. 예를 들어 web.xml, ejb-jar.xml, application.xml 등이다.
Java EE는 제가 직접 경험한 예입니다.하지만 XML은 당시 기업계에서 없는 곳이 없었다.그 유행은 두 가지 측면에 나타난다. 그것이 바로 설정과 데이터 전송이다.
그때부터 완곡하게 말하자면 XML은 이미 더 이상 유행하지 않았다.JSON과 YAML 같은 다른 형식은 개발자들의 마음속에서 이미 그것을 대체했다.이 문장에서 나는 다음과 같이 생각한다.

강력한 XML 하락의 일부 원인 탐색

은 유행 대체 방안인

의 일부 단점을 제시했다

, XML이 이러한 문제를 어떻게 해결하는지 설명

XML의 쇠퇴

나는 XML의 쇠퇴를 초래한 몇 가지 원인이 있다고 생각한다.이것은 단일한 문제가 아니라 그것들의 결합이 현재의 상태를 초래했다.

엔터프라이즈 관련

아마도 XML의 가장 큰 결함은 기업계와의 밀접한 관계일 것이다.모두가 알다시피 기업은 엉망으로 유명하다. 말 그대로 비대하고 무겁고 융통성이 없다. 그래, 알고 싶다면 이것이 풍자다.
전반적으로 말하면 감지가 진리보다 낫다.개발자도 이 방면에서 별다른 차이가 없다.마지막으로 이것이 바로 현재 드라이브를 휘두르는 개발자와 대부분의 개발자들이 XML을 어떻게 생각하는가이다.

프런트엔드와의 통합 부족

XML의 주요 용도 중 하나는 SOAP web services 영역입니다.솔직히 자바스크립트 및/또는 브라우저에서 이러한 웹 서비스를 사용하는 어려움은 놀랍지 않다.
어쩐지 JSON이라는 JavaScript 객체 표현이 사실상의 표준이 되었더라니.JSON은 REST을 가지고 왔습니다.말 그대로 JSON은 XML이 아닌 JavaScript 본체입니다.

가파른 첫걸음

JSON은 시작하기 쉬운데, YAML은 더욱 그렇다.누드 XML을 사용하더라도 이름 공간의 개념이 있기 때문에 초보자에게는 결코 우호적이지 않다.XML을 사용하면 문서에서 다른 이름 공간에서 요소를 사용할 수 있습니다.다른 한편, 그것은 간단한 문서를 설계하는 것을 더욱 복잡하게 한다.
XML에는 강력한 기능이 많지만 모든 기능은 초보자들을 곤혹스럽게 한다.나는 그들이 간단한 일을 그들이 해야 할 일보다 더 복잡하게 만들었다는 것을 흔쾌히 인정한다.

공연

나는 몇 차례 우연히 성능 논쟁을 발견했다.이것은 일반적으로 XML, JSON 및 YAML에서 동일한 내용을 설명하는 예시를 사용하여 증명됩니다.시작과 끝 표시로 인해 저자는 다른 두 표시에 비해 XML이 매우 시끄럽다고 밝혔다.
응, 이 논점은 매우 천박하다. 왜냐하면 이 세 가지 격식은 모두 텍스트에 기초한 것이기 때문이다.따라서 파일을 압축할 수 있고 압축해야 합니다.해석이 좀 느릴 수 있지만, 이것은 어느 정도 정확한 해석기(및 관련 기술 창고)에 달려 있다.마지막으로 전체 용례의 총 시간과 비교하면 XML에서 전송하고 해석하는 비용은 무시할 수 있다.
JSON이 아닌 YAML을 지원하는 사람들은 같은 추리를 사용합니다. 더 적은 문자입니다.

활용단어참조

이러한 이유는 XML과 일치하는 경우가 많거나 적습니다.하지만 프로그래머가 XML을 남용하고 있다는 것을 인정하고 싶습니다.개인적으로 수 메가바이트의 부하가 있는 SOAP 웹 서비스를 본 적이 있습니다.그때는 이런 디자인의 성능이 결코 뛰어나지 않다고 상상할 수도 있다.

대안 실패

JSON, YAML, 알은 모두 자신의 결점이 있다.다음은 예입니다.

JSON에 주석이 없습니다.가장 흔히 볼 수 있는 반환 방법은 "_comment" 속성을 사용하는 것이다.

{
  "foo": {
    "_comment" : "My important comment",
    "bar": true
  }
}

YAML에 관리 기관이 없습니다.개인 관리 규범.

YAML에는 부울 값을 작성하는 22가지 방법이 있습니다.

Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway.

    -- Nobody wants to write YAML

니콜라스 프랭클
@ 니콜라스 프랭클

YAML의 문법 설정은 Python의 프로그래밍 언어 설정과 같습니다.정말이지, 중요한 공백?500줄의 YAML로 쿠베르네츠 배치를 설정하고 즐겁게 놀다가 왜 싫은지 설명해 보세요.
2020년 6월 19일 오전 07:59

이러한 상황에 대처하기 위해 다른 형식이 등장했다.

TOML의 영감은 https://en.wikipedia.org/wiki/INI_file 형식에서 나온다.그것은

속성의 끼워 넣는 차원 구조를 허용한다

Lightbend는 HOCON 형식을 사용합니다.

This is an informal spec, but hopefully it's clear.

    -- HOCON README

이 한마디는 결코 나로 하여금 자신감을 가지게 하지 않았다.

원죄: 문법 결여

형식이 어떻든 그 자체의 구체적인 결점이 어떻든 간에 가장 중요한 문제 중 하나는 클라이언트가 읽은 데이터가 정확한지 확인하는 것이다.
JSON과 YAML을 사용할 때 서로 다른 클라이언트는 특별 인증을 제공해야 합니다.공급자가 데이터 형식을 변경하면 다음과 같은 문제가 발생합니다.

은 어떻게 고객에게 형식이 바뀌었다는 것을 깨닫게 합니까?

형식 변경에 대해 고객에게 어떤 정보를 전달해야 합니까?

은 어떻게 클라이언트 간에 검증 동기화를 유지합니까?

XML은 처음부터 문법을 제공함으로써 이 문제를 해결했다.XML 문서에 대한 구문은 SQL 데이터베이스의 제약조건 및 유형과 동일합니다.가장 중요한 차이점은 네가 문법을 구체화할 수 있다는 것이다.
몇 가지 XML 문법이 실현된다. Document Type Definition, XML Schema, Relax NG 등이다. 가장 광범위한 것은 XML 모델이다.XML 모드도 XML 형식으로 작성되기 때문에 웹 서버에서 관리할 수 있습니다.그런 다음 공개적으로 액세스할 수 있는 URL을 통해 참조할 수 있습니다.
이 방법은 클라이언트가 XML 문서를 받았을 때 전자가 XML 모드 URL을 보는 문제를 해결했다.그리고 그것을 얻을 수 있고 데이터가 패턴에 부합되는지 검사할 수 있다.
데이터 형식을 변경하는 것은 매우 간단합니다. XML 모드 파일의 버전을 제어한 다음 새 URL 아래에 발표하기만 하면 됩니다.

XML의 다른 이점

이 섹션에서는 XML을 사용하는 몇 가지 이점을 열거하고 싶습니다.

공개 관리

XML은 한 사람이나 한 회사에서 관리하는 것이 아니라 비정부 조직(즉 W3C)에서 관리한다.W3C 규범은 publicly documented process and defined lifecycle을 가지고 있다.

전투 증명서

XML은 결코 선전하는 것이 아니지만, 대량의 문서, 블로그 게시물, FAQs의 이익을 얻는다

조합 가능

XML은 이름 공간을 엄격하게 실행하지는 않지만 좋은 방법으로 여겨진다.이렇게 하면 서로 다른 이름 공간에서 정의된 유사한 이름 실체는 같은 문서에 공존할 수 있고 의미를 혼동하지 않는다.

다른 맛

XML 해석에는 다음과 같은 두 가지 스타일이 있습니다.

은 나무의 해석, 즉 Document Object Model을 바탕으로 한다.전체 문서를 메모리

에 로드합니다.

은 사건의 해석, 즉 Simple API for XML을 바탕으로 한다.그것은 대형 문서의 해석을 가능하게 한다.

SAX는 W3C 사양이 아닙니다.

서로 다른 언어의 실현:

업계의 모든 상용 언어는 적어도 하나의 XML 해석 실현을 제공한다.이것은 이 언어에 첨부된 표준 라이브러리에서 베이킹하거나 제3자 라이브러리에서 제공한다.다음은 다음 중 몇 가지입니다.
언어
실시
DOM
색소폰
메모
Java 언어
Standard Library
✅
❌
Java 언어
Standard Library
❌
✅
루비
Nokogiri
✅
✅
libxml2 패키지
구렁이
Standard library
✅
✅
가다
Standard Library
✅
❌
가다
Gogogiri
?
✅
libxml2 패키지
C#
Standard Library
✅
❌
C
libxml2
✅
✅
C
libexpat
❌
✅
C++
pugixml
✅
❌
C++
Xerces
✅
✅
둘째 아들
Standard library
✅
❌
둘째 아들
Fast XML
✅
✅
노드 JS
libxmljs
✅
✅
libxml 패키지
노드 JS
node-expat
❌
✅
libexpat을 둘러싼 포장

문서 변환

XSLT는 a W3C specification입니다.XML 문서를 선언식으로 다른 문서로 변환할 수 있습니다.대상 문서는 XML 자체일 수도 있고 아닐 수도 있습니다.

문서 질의

XPath는 another W3C specification입니다.CSS 선택기와 같은 XML 문서를 질의하는 방법을 정의합니다.

결론

다른 대체 기술에 비해 XLM은 많은 장점을 가지고 있습니다.상술한 내용 외에도 rich ecosystem의 이익을 얻었다.
많은 젊은 개발자들이 이것이 투기라고 생각하지 않는다.나는 만약 우리 업계가 새로운 반짝이는 기술이 아니라 전투 검증을 거친 기술을 중시한다면 유익할 것이라고 믿는다.
더 나아가서:

Introducing JSON

The JavaScript Object Notation (JSON) Data Interchange Format

YAML Ain't Markup Language

YAML Ain’t Markup Language (YAML™) v1.2

Nobody wants to write YAML

Tom’s Obvious, Minimal Language

eXtensible Markup Language (W3C recommandation)

최초 2020년 9월 27일 A Java Geek 발표