"XML"의 두 판 사이의 차이
(→문제점) |
잔글 (→같이 보기) |
||
(사용자 3명의 중간 판 51개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | [[파일:XML.png|썸네일|200픽셀|'''XML'''( | + | [[파일:XML 로고.png|썸네일|200픽셀|'''XML'''(Extensible Markup Language)]] |
+ | [[파일:XML 글자.png|썸네일|300픽셀|'''XML'''(Extensible Markup Language)]] | ||
'''XML'''(엑스엠엘)은 Extensible Markup Language의 약자로서, [[홈페이지]] 제작에 사용되는 "확장된 HTML 언어"이다. [[HTML]] 언어는 미리 정의된 [[태그]]만 사용할 수 있지만, XML 언어는 필요한 태그(tag)를 개발자가 새로 정의하여 사용할 수 있다. 다양한 [[시스템]]을 [[연계]]하여 [[데이터]]를 주고받기 위해 XML 기반의 [[SOAP]] 또는 [[REST]] 방식을 사용한다. | '''XML'''(엑스엠엘)은 Extensible Markup Language의 약자로서, [[홈페이지]] 제작에 사용되는 "확장된 HTML 언어"이다. [[HTML]] 언어는 미리 정의된 [[태그]]만 사용할 수 있지만, XML 언어는 필요한 태그(tag)를 개발자가 새로 정의하여 사용할 수 있다. 다양한 [[시스템]]을 [[연계]]하여 [[데이터]]를 주고받기 위해 XML 기반의 [[SOAP]] 또는 [[REST]] 방식을 사용한다. | ||
7번째 줄: | 8번째 줄: | ||
== 등장배경 == | == 등장배경 == | ||
− | XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 [[데이터]]를 쉽게 | + | XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 [[데이터]]를 쉽게 주고받을 수 있게 하여 [[HTML]]의 한계를 극복할 목적으로 만들어졌다. XML을 이용하면 어디부터 어디까지가 [[데이터]] 이름이고 어디부터 어디까지가 실제 [[데이터]]이며 어디부터 어디까지가 [[데이터]] 단위인지도 표현할 수 있다. 즉, [[데이터]]에 의미를 부여하는 메타데이터를 기술할 수 있다. XML은 바로 이러한 목적으로 탄생했다. |
== 역사 == | == 역사 == | ||
XML은 SGML의 애플리케이션 프로파일이다. | XML은 SGML의 애플리케이션 프로파일이다. | ||
− | 동적 정보 표시를 위한 [[SGML]]의 다재다능함은 인터넷의 성장 이전인 1980년대 말에 초기 디지털 미디어 출판사들에 의해 인지되었다. 1990년대 중순, 일부 [[SGML]] 실천자들은 당시 새로운 [[월드 와이드 웹]]을 경험하였고 웹이 성장할수록 마주칠 가능성이 있던 | + | 동적 정보 표시를 위한 [[SGML]]의 다재다능함은 인터넷의 성장 이전인 1980년대 말에 초기 디지털 미디어 출판사들에 의해 인지되었다. 1990년대 중순, 일부 [[SGML]] 실천자들은 당시 새로운 [[월드 와이드 웹]]을 경험하였고 웹이 성장할수록 마주칠 가능성이 있던 문제 중 일부를 SGML이 해결해줄 것이라 믿었다. 댄 커널리는 1995년 당시 직원으로 있었을 때 SGML을 [[W3C]]의 활동 목록에 추가하였다. 작업은 1996년 중순 썬 마이크로시스템즈의 엔지니어 존 보삭이 선언문을 만들고 협업자들을 모집하였을 때 시작되었다. 보삭은 [[SGML]]과 웹에 모두 경험이 있는 사람들의 작은 공동체와 잘 어울렸다. |
− | 주요 디자인 결정은 1996년 7월과 11월 사이 도달했으며, 당시 XML 사양의 최초 워킹 드래프트가 출판되었다. 추가 디자인 작업이 1997년에 계속되었으며 XML 1.0은 1998년 2월 10일 [[W3C]] 권고안이 되었다. <ref name="XML개념> 〈[https://ko.wikipedia.org/ | + | 주요 디자인 결정은 1996년 7월과 11월 사이 도달했으며, 당시 XML 사양의 최초 워킹 드래프트가 출판되었다. 추가 디자인 작업이 1997년에 계속되었으며 XML 1.0은 1998년 2월 10일 [[W3C]] 권고안이 되었다. <ref name="XML개념> 〈[https://ko.wikipedia.org/wiki/XML XML]〉,《위키백과》 </ref> |
== 특징 == | == 특징 == | ||
26번째 줄: | 27번째 줄: | ||
*XML은 모듈식이다. | *XML은 모듈식이다. | ||
*XML은 RDF와 시맨틱 웹의 토대이다. | *XML은 RDF와 시맨틱 웹의 토대이다. | ||
− | *XML은 라이선스 제약이 없으며, 플랫폼이 독립적이고, 많은 지원이 있다.<ref name="XML개념"></ref> | + | *XML은 라이선스 제약이 없으며, 플랫폼이 독립적이고, 많은 지원이 있다. |
+ | |||
+ | XML(Extensible Markup Language)은 W3C에서 개발된, 다른 특수한 목적을 갖는 마크업 언어를 만드는 데 사용하도록 권장하는 다목적 마크업 언어이다. XML은 SGML의 단순화된 부분집합으로, 다른 많은 종류의 데이터를 기술하는 데 사용할 수 있다. XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고받을 수 있게 하여 HTML의 한계를 극복할 목적으로 만들어졌다. | ||
+ | |||
+ | 기계는 인간의 언어를 읽거나 이해할 수 없는 계산기에 불과하므로 XML과 같은 구조화된 마크업 언어들은 인간의 읽고 분석하여 이해하는 능력과 컴퓨터의 단순한 계산적인 판독 능력 사이에 타협점을 만들어 줄 수 있다. W3C가 만든 XML 1.0 Specification과 몇몇 다른 관련 명세들과 모든 자유 개방형 표준에서 정의되었다. | ||
+ | |||
+ | W3C는 XML 설계 목표에서 단순성과 일반성, 그리고 인터넷을 통한 사용 가능성을 강조했다. XML은 텍스트 데이터 형식으로 유니코드를 사용해 전 세계 언어를 지원한다. XML을 설계할 때는 주로 문서를 표현하는데 집중했지만, 지금은 임의의 자료구조를 나타내는 데 널리 쓰인다. 대표적인 예가 웹 서비스이다. | ||
+ | |||
+ | 많은 API가 개발되어 XML 데이터를 처리하고자 하는 소프트웨어 개발자들이 활용하고 있다. 또한, 여러 가지 스키마 시스템이 있어서 XML 기반 언어의 정의를 더욱 쉽게 할 수 있도록 도와준다.<ref name="XML개념"></ref> | ||
== 활용 == | == 활용 == | ||
− | XML은 어디까지나 구조를 가지면서 메타데이터를 기술할 수 있는 다목적 문서 형식 표준이다. 이를 원하는 용도에 맞게 DTD, XML Schema를 작성하고 표준으로 제정하면 XML에 기반한 특수 목적용 마크업 언어가 된다. (무리가 있는 비유지만) XML과 XML을 사용하는 다른 마크업 언어는 마치 한국어와 한국어로 쓰인 시, 소설, 수필, 학술논문, | + | XML은 어디까지나 구조를 가지면서 메타데이터를 기술할 수 있는 다목적 문서 형식 표준이다. 이를 원하는 용도에 맞게 DTD, XML Schema를 작성하고 표준으로 제정하면 XML에 기반한 특수 목적용 마크업 언어가 된다. (무리가 있는 비유지만) XML과 XML을 사용하는 다른 마크업 언어는 마치 한국어와 한국어로 쓰인 시, 소설, 수필, 학술논문, 영화 대본, 신문 기사 등과 유사한 관계라고 할 수 있다. |
− | 누구나 알 수 있는 이러한 것의 대표적인 예로 초기의 RSS를 들 수 있다. 처음엔 이름이 RDF Site | + | 누구나 알 수 있는 이러한 것의 대표적인 예로 초기의 RSS를 들 수 있다. 처음엔 이름이 RDF Site Summary였으나, 나중에 Rich Site Summary로 변경되면서 XML 형식도 약간 변경이 되었는데, 이는 초기 버젼이 Resource Description Framework(RDF)라는 XML 기반의 의미 정보를 엄격하게 기술하는 마크업 언어로 되어있었기 때문이다. |
− | 그 밖에 Java로 웹 어플리케이션을 작성해 본 사람이면 web.xml | + | 그 밖에 Java로 웹 어플리케이션을 작성해 본 사람이면 web.xml 설정 파일이 친숙할 텐데, 이것도 Oracle(과거 Sun Microsystems)에서 XML Schema로 형식을 규정한 JSP/Servlet Web Application 표준 설정 파일이다. |
− | C#에서는 프로그램 설정에 사용하는 App.config, WPF에서 사용하는 Xaml 파일이 있다.<ref> 〈[https://namu.wiki/w/XML | + | C#에서는 프로그램 설정에 사용하는 App.config, WPF에서 사용하는 Xaml 파일이 있다.<ref> 〈[https://namu.wiki/w/XML XML]〉,《나무위키》 </ref> |
== 종류 == | == 종류 == | ||
49번째 줄: | 58번째 줄: | ||
이 절의 내용은 XML 명세에 기반한다. XML에 나타나는 모든 요소의 목록이 아니다. 가장 많이 쓰이는 핵심 요소만을 소개한다. | 이 절의 내용은 XML 명세에 기반한다. XML에 나타나는 모든 요소의 목록이 아니다. 가장 많이 쓰이는 핵심 요소만을 소개한다. | ||
==== 유니코드 문자 ==== | ==== 유니코드 문자 ==== | ||
− | + | 정의상, XML 문서는 문자로 이루어진 문자열이다. 거의 모든 올바른 유니코드 문자는 XML 문서에 나타날 수 있다.<ref name="XML개념"></ref> | |
+ | |||
==== 프로세서(processor)와 애플리케이션(application) ==== | ==== 프로세서(processor)와 애플리케이션(application) ==== | ||
− | 프로세서는 마크업을 분석하고 구조화된 정보를 애플리케이션에 넘긴다. 이 명세는 XML 프로세서가 무엇을 | + | 프로세서는 마크업을 분석하고 구조화된 정보를 애플리케이션에 넘긴다. 이 명세는 XML 프로세서가 무엇을 해야 하고 하지 말아야 하는지 제시하지만, 애플리케이션에 대해서는 다루지 않는다. 이 프로세서(명세가 부르기를)는 흔히 XML parser라 불린다.<ref name="XML개념"></ref> |
==== 마크업(markup)과 내용(content) ==== | ==== 마크업(markup)과 내용(content) ==== | ||
− | XML 문서를 구성하는 문자들은 마크업과 내용으로 나뉘는데, 그 구분은 간단한 문법 규칙으로 이루어진다. 일반적으로 마크업을 구성하는 문자열은 문자 <로 시작하여 문자 >로 끝나거나, 문자 &로 시작하여 문자 ;로 끝나며, 마크업이 아닌 문자열은 내용이다. 그러나, CDATA 절에서, 구분자 | + | XML 문서를 구성하는 문자들은 마크업과 내용으로 나뉘는데, 그 구분은 간단한 문법 규칙으로 이루어진다. 일반적으로 마크업을 구성하는 문자열은 문자 <로 시작하여 문자 >로 끝나거나, 문자 &로 시작하여 문자 ;로 끝나며, 마크업이 아닌 문자열은 내용이다. 그러나, CDATA 절에서, 구분자 CDATA와 는 마크업으로 분류되고,그들 사이의 텍스트는 내용으로 구분된다. 추가로, 가장 바깥 엘리먼트의 앞과 뒤의 공백(whitespace)은 마크업으로 분류된다.<ref name="XML개념"></ref> |
+ | |||
==== 태그(tag) ==== | ==== 태그(tag) ==== | ||
<로 시작하여 >로 끝나는 마크업 구조. 태그는 세 가지 종류가 있다. | <로 시작하여 >로 끝나는 마크업 구조. 태그는 세 가지 종류가 있다. | ||
60번째 줄: | 71번째 줄: | ||
*끝 태그(end-tag); 예: </section> | *끝 태그(end-tag); 예: </section> | ||
*빈 엘리먼트(empty-element) 태그; 예: <line-break /><ref name="XML개념"></ref> | *빈 엘리먼트(empty-element) 태그; 예: <line-break /><ref name="XML개념"></ref> | ||
+ | |||
==== 엘리먼트(element) ==== | ==== 엘리먼트(element) ==== | ||
− | 문서의 논리 요소로서, 시작 태그로 시작하여 짝이 되는 끝 태그로 끝나거나, 빈 엘리먼트 태그만으로 이루어진다. 시작 태그와 끝 태그 사이의 문자들은(있다면) 엘리먼트의 내용이고, 마크업을 포함할 수 있다. 이 | + | 문서의 논리 요소로서, 시작 태그로 시작하여 짝이 되는 끝 태그로 끝나거나, 빈 엘리먼트 태그만으로 이루어진다. 시작 태그와 끝 태그 사이의 문자들은(있다면) 엘리먼트의 내용이고, 마크업을 포함할 수 있다. 이 마크업은 자식 엘리먼트(child elements)라 부르는 다른 엘리먼트들을 포함할 수도 있다. |
엘리먼트의 예는 | 엘리먼트의 예는 | ||
− | + | Greeting>Hello, world.</Greeting> (see hello world). | |
다른 예는 | 다른 예는 | ||
− | + | line-break />.<ref name="XML개념"></ref> | |
==== 애트리뷰트(Attribute) ==== | ==== 애트리뷰트(Attribute) ==== | ||
이름/값 짝으로 이루어진 마크업 구조로 시작할 수 있다. | 이름/값 짝으로 이루어진 마크업 구조로 시작할 수 있다. | ||
− | + | <img src="madonna.jpg" alt='Foligno Madonna, by Raphael'/> | |
다른 예로 | 다른 예로 | ||
− | + | <step number="3">Connect A to B.</step> | |
에서 애트리뷰트 이름은 "number"이고 값은 "3"이다.<ref name="XML개념"></ref> | 에서 애트리뷰트 이름은 "number"이고 값은 "3"이다.<ref name="XML개념"></ref> | ||
==== XML 선언 ==== | ==== XML 선언 ==== | ||
XML 문서는 다음과 같이 자신에 대한 정보 일부를 선언하는 것으로 시작할 수 있다. | XML 문서는 다음과 같이 자신에 대한 정보 일부를 선언하는 것으로 시작할 수 있다. | ||
− | + | <?xml version="1.0" encoding="UTF-8" ?><ref name="XML개념"></ref> | |
== 문제점 == | == 문제점 == | ||
− | |||
JSON과 비교하여 보았을 때 | JSON과 비교하여 보았을 때 | ||
− | *복잡성 : 의도적으로 간결함과 집중을 추구한 툴인 JSON에 비해 복잡하고 구조화된 개념 대부분을 단독으로 표현하는 XML은 | + | *복잡성 : 의도적으로 간결함과 집중을 추구한 툴인 JSON에 비해 복잡하고 구조화된 개념 대부분을 단독으로 표현하는 XML은 유용하지 않다는 인식이 있다. |
− | *보안 : JSON을 이용해 위험에 노출되는 툴을 개발하기는 어렵지만 XML을 사용할 때는 반드시 개발자가 능동적으로 확인하고 피해야 한다. 그리고 XML은 적절하게 파싱(Parsing)을 거쳐도 BL(Billion Laughs) 공격 또는 EE(External Entity) 공격 같은 보안 취약성을 일부 갖고 있다. | + | *보안 : JSON을 이용해 위험에 노출되는 툴을 개발하기는 어렵지만, XML을 사용할 때는 반드시 개발자가 능동적으로 확인하고 피해야 한다. 그리고 XML은 적절하게 파싱(Parsing)을 거쳐도 BL(Billion Laughs) 공격 또는 EE(External Entity) 공격 같은 보안 취약성을 일부 갖고 있다. |
− | *자바스크립트: JSON은 자바스크립트로 작성됐다. 본래 자바스크립트와의 손쉬운 상호운용성을 위해 자바스크립트에서 사용하는 문법을 그 자체의 데이터 형식으로 뽑아내도록 정의됐다. | + | *자바스크립트 : JSON은 자바스크립트로 작성됐다. 본래 자바스크립트와의 손쉬운 상호운용성을 위해 자바스크립트에서 사용하는 문법을 그 자체의 데이터 형식으로 뽑아내도록 정의됐다. |
− | *툴 지원: JSON의 인기가 높아지면서 더 많은 개발자 툴이 이를 표준으로 받아들이고 있다. | + | *툴 지원 : JSON의 인기가 높아지면서 더 많은 개발자 툴이 이를 표준으로 받아들이고 있다. |
− | + | 이러한 단점들이 있고 프로그래밍 언어나 데이터베이스의 시스템을 입력하기 위해 XML을 맵핑(Mapping)하기가 어렵고, 데이터가 특정 애플리케이션에 맞춰 구조화된 경우에는 더 까다롭다. 또한 많은 태그 때문에 문자량이 늘어나 응답 시간이 느리다. | |
− | |||
− | |||
− | |||
{{각주}} | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
+ | *W3C 공식 홈페이지 - https://www.w3.org/ | ||
+ | *Andy Patrizio, 〈[http://www.ciokorea.com/tags/16087/JSON/30044 XML을 위해 건배, JSON이여 영원하라]〉, 《씨아이오코리아》, 2016-06-13 | ||
+ | *〈[https://ko.wikipedia.org/wiki/XML XML]〉, 《위키백과》 | ||
+ | *〈[https://namu.wiki/w/XML XML]〉, 《나무위키》 | ||
== 같이 보기 == | == 같이 보기 == | ||
* [[HTML]] | * [[HTML]] | ||
+ | * [[JSON]] | ||
− | {{ | + | {{시스템 연계|검토 필요}} |
[[분류:퍼블리싱]] | [[분류:퍼블리싱]] |
2021년 8월 7일 (토) 02:42 기준 최신판
XML(엑스엠엘)은 Extensible Markup Language의 약자로서, 홈페이지 제작에 사용되는 "확장된 HTML 언어"이다. HTML 언어는 미리 정의된 태그만 사용할 수 있지만, XML 언어는 필요한 태그(tag)를 개발자가 새로 정의하여 사용할 수 있다. 다양한 시스템을 연계하여 데이터를 주고받기 위해 XML 기반의 SOAP 또는 REST 방식을 사용한다.
목차
개요[편집]
W3C에서 여러 특수 목적의 마크업 언어를 만드는 용도에서 권장되는 다목적 마크업 언어이다. 첨언하자면 마크업 언어는 태그 등을 이용하여 데이터의 구조를 기술하는 언어의 한 가지이다. 가장 친숙하고 흔하게 접할 수 있는 마크업 언어로 HTML이 있다. 또한 XML은 SGML의 단순화된 부분집합으로, 다른 많은 종류의 데이터를 기술하는 데 사용할 수 있다.
등장배경[편집]
XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고받을 수 있게 하여 HTML의 한계를 극복할 목적으로 만들어졌다. XML을 이용하면 어디부터 어디까지가 데이터 이름이고 어디부터 어디까지가 실제 데이터이며 어디부터 어디까지가 데이터 단위인지도 표현할 수 있다. 즉, 데이터에 의미를 부여하는 메타데이터를 기술할 수 있다. XML은 바로 이러한 목적으로 탄생했다.
역사[편집]
XML은 SGML의 애플리케이션 프로파일이다.
동적 정보 표시를 위한 SGML의 다재다능함은 인터넷의 성장 이전인 1980년대 말에 초기 디지털 미디어 출판사들에 의해 인지되었다. 1990년대 중순, 일부 SGML 실천자들은 당시 새로운 월드 와이드 웹을 경험하였고 웹이 성장할수록 마주칠 가능성이 있던 문제 중 일부를 SGML이 해결해줄 것이라 믿었다. 댄 커널리는 1995년 당시 직원으로 있었을 때 SGML을 W3C의 활동 목록에 추가하였다. 작업은 1996년 중순 썬 마이크로시스템즈의 엔지니어 존 보삭이 선언문을 만들고 협업자들을 모집하였을 때 시작되었다. 보삭은 SGML과 웹에 모두 경험이 있는 사람들의 작은 공동체와 잘 어울렸다.
주요 디자인 결정은 1996년 7월과 11월 사이 도달했으며, 당시 XML 사양의 최초 워킹 드래프트가 출판되었다. 추가 디자인 작업이 1997년에 계속되었으며 XML 1.0은 1998년 2월 10일 W3C 권고안이 되었다. [1]
특징[편집]
- XML은 구조적인 데이터를 위한 것이다.
- XML은 다소 HTML 같이 보인다.
- XML은 텍스트이며, 읽히는 것만을 뜻하지 않는다.
- XML은 크기가 커진다.
- XML은 기술의 집합이다.
- XML은 새로운 기술이 아니라 발전한 기술이다.
- XML은 HTML에서 XHTML로 이끌었다.
- XML은 모듈식이다.
- XML은 RDF와 시맨틱 웹의 토대이다.
- XML은 라이선스 제약이 없으며, 플랫폼이 독립적이고, 많은 지원이 있다.
XML(Extensible Markup Language)은 W3C에서 개발된, 다른 특수한 목적을 갖는 마크업 언어를 만드는 데 사용하도록 권장하는 다목적 마크업 언어이다. XML은 SGML의 단순화된 부분집합으로, 다른 많은 종류의 데이터를 기술하는 데 사용할 수 있다. XML은 주로 다른 종류의 시스템, 특히 인터넷에 연결된 시스템끼리 데이터를 쉽게 주고받을 수 있게 하여 HTML의 한계를 극복할 목적으로 만들어졌다.
기계는 인간의 언어를 읽거나 이해할 수 없는 계산기에 불과하므로 XML과 같은 구조화된 마크업 언어들은 인간의 읽고 분석하여 이해하는 능력과 컴퓨터의 단순한 계산적인 판독 능력 사이에 타협점을 만들어 줄 수 있다. W3C가 만든 XML 1.0 Specification과 몇몇 다른 관련 명세들과 모든 자유 개방형 표준에서 정의되었다.
W3C는 XML 설계 목표에서 단순성과 일반성, 그리고 인터넷을 통한 사용 가능성을 강조했다. XML은 텍스트 데이터 형식으로 유니코드를 사용해 전 세계 언어를 지원한다. XML을 설계할 때는 주로 문서를 표현하는데 집중했지만, 지금은 임의의 자료구조를 나타내는 데 널리 쓰인다. 대표적인 예가 웹 서비스이다.
많은 API가 개발되어 XML 데이터를 처리하고자 하는 소프트웨어 개발자들이 활용하고 있다. 또한, 여러 가지 스키마 시스템이 있어서 XML 기반 언어의 정의를 더욱 쉽게 할 수 있도록 도와준다.[1]
활용[편집]
XML은 어디까지나 구조를 가지면서 메타데이터를 기술할 수 있는 다목적 문서 형식 표준이다. 이를 원하는 용도에 맞게 DTD, XML Schema를 작성하고 표준으로 제정하면 XML에 기반한 특수 목적용 마크업 언어가 된다. (무리가 있는 비유지만) XML과 XML을 사용하는 다른 마크업 언어는 마치 한국어와 한국어로 쓰인 시, 소설, 수필, 학술논문, 영화 대본, 신문 기사 등과 유사한 관계라고 할 수 있다.
누구나 알 수 있는 이러한 것의 대표적인 예로 초기의 RSS를 들 수 있다. 처음엔 이름이 RDF Site Summary였으나, 나중에 Rich Site Summary로 변경되면서 XML 형식도 약간 변경이 되었는데, 이는 초기 버젼이 Resource Description Framework(RDF)라는 XML 기반의 의미 정보를 엄격하게 기술하는 마크업 언어로 되어있었기 때문이다.
그 밖에 Java로 웹 어플리케이션을 작성해 본 사람이면 web.xml 설정 파일이 친숙할 텐데, 이것도 Oracle(과거 Sun Microsystems)에서 XML Schema로 형식을 규정한 JSP/Servlet Web Application 표준 설정 파일이다.
C#에서는 프로그램 설정에 사용하는 App.config, WPF에서 사용하는 Xaml 파일이 있다.[2]
종류[편집]
- DOM : XML 문서가 전부 메모리로 올라가 객체 모델로 만들어진다. W3C의 공식 표준이며, W3C가 표준화한 API들의 기반이다. 문서가 통째로 메모리에 올라가 조직화하기 때문에 문서 요소를 임의로 접근하고 사용하기에 용이하다. 그러나 이는 반대로 단점이 되기도 하는데, 논리 구조를 통째로 메모리에 올려놓고 연산하기 때문에 XML 데이터의 양이 많으면 메모리 부족으로 인해 고생하게 된다.
- SAX : XML 문서를 애플리케이션에서 사용하기 위한 API. DOM과 비교해 저수준의 인터페이스를 가지고 있으며 처리해야 할 파일이 클 때 적합하다. XML의 구조에 따라 이벤트가 발생하며, 프로그래머는 이 이벤트를 처리하는 이벤트 핸들러를 작성하여 필요한 데이터를 추출할 수 있다. 이러한 이유로 데이터 내용을 조직하는 기능은 DOM만 못하다. XML 문서를 통으로 메모리상에 논리 구조를 유지하면서 올리고 작업할 수 없기 때문이다. 그러나 이러한 이벤트 기반 처리 방식은 역시 읽어서 처리해야 하는 XML 데이터가 매우 클 때 장점으로 발휘한다. 일단 어떻게든 다른 대용량 비휘발성 저장공간(데이터베이스, NoSQL 등)에 입력하는 데 SAX를 쓰고, 데이터 조작은 해당 저장공간에서 하면 되기 때문이다.
또한 SAX 파서는 내 결함 성을 갖게 만들 수 있게 되어 일부 손상된 XML도 읽어서 처리할 수 있다.
둘 다 모두 실제 구현체가 아닌 인터페이스 수준으로 느슨하게 정의되어 있다. 그래서 프로그래밍 언어/플랫폼별로 실제 사용 방법이 약간 다를 수 있다. XML이 초기에 널리 퍼진 이유 중 하나는 대부분 언어에서 기본으로 지원하는 구조화된 데이터를 읽는 기본 API 보다 훨씬 복잡한 형태의 구조화된 데이터를 읽고 쓰는데 편리했기 때문이다. 지금은 웹 관련 한정으로 JSON이 더 많이 쓰이고 있다.
중요 용어[편집]
이 절의 내용은 XML 명세에 기반한다. XML에 나타나는 모든 요소의 목록이 아니다. 가장 많이 쓰이는 핵심 요소만을 소개한다.
유니코드 문자[편집]
정의상, XML 문서는 문자로 이루어진 문자열이다. 거의 모든 올바른 유니코드 문자는 XML 문서에 나타날 수 있다.[1]
프로세서(processor)와 애플리케이션(application)[편집]
프로세서는 마크업을 분석하고 구조화된 정보를 애플리케이션에 넘긴다. 이 명세는 XML 프로세서가 무엇을 해야 하고 하지 말아야 하는지 제시하지만, 애플리케이션에 대해서는 다루지 않는다. 이 프로세서(명세가 부르기를)는 흔히 XML parser라 불린다.[1]
마크업(markup)과 내용(content)[편집]
XML 문서를 구성하는 문자들은 마크업과 내용으로 나뉘는데, 그 구분은 간단한 문법 규칙으로 이루어진다. 일반적으로 마크업을 구성하는 문자열은 문자 <로 시작하여 문자 >로 끝나거나, 문자 &로 시작하여 문자 ;로 끝나며, 마크업이 아닌 문자열은 내용이다. 그러나, CDATA 절에서, 구분자 CDATA와 는 마크업으로 분류되고,그들 사이의 텍스트는 내용으로 구분된다. 추가로, 가장 바깥 엘리먼트의 앞과 뒤의 공백(whitespace)은 마크업으로 분류된다.[1]
태그(tag)[편집]
<로 시작하여 >로 끝나는 마크업 구조. 태그는 세 가지 종류가 있다.
- 시작 태그(start-tag); 예: <section>
- 끝 태그(end-tag); 예: </section>
- 빈 엘리먼트(empty-element) 태그; 예: <line-break />[1]
엘리먼트(element)[편집]
문서의 논리 요소로서, 시작 태그로 시작하여 짝이 되는 끝 태그로 끝나거나, 빈 엘리먼트 태그만으로 이루어진다. 시작 태그와 끝 태그 사이의 문자들은(있다면) 엘리먼트의 내용이고, 마크업을 포함할 수 있다. 이 마크업은 자식 엘리먼트(child elements)라 부르는 다른 엘리먼트들을 포함할 수도 있다. 엘리먼트의 예는
Greeting>Hello, world.</Greeting> (see hello world).
다른 예는
line-break />.[1]
애트리뷰트(Attribute)[편집]
이름/값 짝으로 이루어진 마크업 구조로 시작할 수 있다.
<img src="madonna.jpg" alt='Foligno Madonna, by Raphael'/>
다른 예로
<step number="3">Connect A to B.</step>
에서 애트리뷰트 이름은 "number"이고 값은 "3"이다.[1]
XML 선언[편집]
XML 문서는 다음과 같이 자신에 대한 정보 일부를 선언하는 것으로 시작할 수 있다.
<?xml version="1.0" encoding="UTF-8" ?>[1]
문제점[편집]
JSON과 비교하여 보았을 때
- 복잡성 : 의도적으로 간결함과 집중을 추구한 툴인 JSON에 비해 복잡하고 구조화된 개념 대부분을 단독으로 표현하는 XML은 유용하지 않다는 인식이 있다.
- 보안 : JSON을 이용해 위험에 노출되는 툴을 개발하기는 어렵지만, XML을 사용할 때는 반드시 개발자가 능동적으로 확인하고 피해야 한다. 그리고 XML은 적절하게 파싱(Parsing)을 거쳐도 BL(Billion Laughs) 공격 또는 EE(External Entity) 공격 같은 보안 취약성을 일부 갖고 있다.
- 자바스크립트 : JSON은 자바스크립트로 작성됐다. 본래 자바스크립트와의 손쉬운 상호운용성을 위해 자바스크립트에서 사용하는 문법을 그 자체의 데이터 형식으로 뽑아내도록 정의됐다.
- 툴 지원 : JSON의 인기가 높아지면서 더 많은 개발자 툴이 이를 표준으로 받아들이고 있다.
이러한 단점들이 있고 프로그래밍 언어나 데이터베이스의 시스템을 입력하기 위해 XML을 맵핑(Mapping)하기가 어렵고, 데이터가 특정 애플리케이션에 맞춰 구조화된 경우에는 더 까다롭다. 또한 많은 태그 때문에 문자량이 늘어나 응답 시간이 느리다.
각주[편집]
참고자료[편집]
- W3C 공식 홈페이지 - https://www.w3.org/
- Andy Patrizio, 〈XML을 위해 건배, JSON이여 영원하라〉, 《씨아이오코리아》, 2016-06-13
- 〈XML〉, 《위키백과》
- 〈XML〉, 《나무위키》
같이 보기[편집]