XML

eXtensible Markup Language의 약어. W3C에서 여러 특수 목적의 마크업 언어를 만드는 용도에서 권장되는 다목적 마크업 언어이다. 마크업 언어는 태그 등을 이용하여 데이터의 구조를 기술하는 언어의 한 가지이다. 가장 친숙하고 흔하게 접할 수 있는 마크업 언어로 HTML이 있다.

1996년 제안된 언어로, 기존의 HTML과 달리 웹상에서 구조화된 문서를 전송가능하도록 설계되었다. 이게 무슨 뜻이냐면 예를 들어 HTML에서는 CPU 2.83GHz라는 데이터를 표기할 때 어디부터가 데이터 명이고 어디부터가 실제 데이터인지 표시할 수 있는 마땅한 방법이 없다.

이런 문제를 해결하기 위해 XML을 이용하면 어디부터 어디까지가 데이터 이름이고 어디부터 어디까지가 실제 데이터이며 어디부터 어디까지가 데이터 단위인지도 표현이 가능하다. 즉, 데이터에 의미를 부여하는 메타데이터를 기술할 수 있다. XML은 바로 이러한 목적으로 탄생했다. 위의 예를 XML로 바꾸면 데이터 명은 <dataname>CPU</dataname>가 되고 데이터 값은 <datavalue>2.83</datavalue>이 된다.

원래 동일한 목적을 가진 Standard Generalized Markup Language(SGML) 라는 것이 인터넷 등장보다 빠른 1980년대에 등장했으며, 이것의 Profile(부분집합)에 인터넷 환경과 새롭게 변화해온 컴퓨팅 환경에 맞게 확장을 더한 것이 바로 XML 이다. XML은 바로 SGML의 파생형이라고 할 수 있으며, HTML은 완전한 파생형은 아니지만 SGML의 영향을 강하게 받았다고 최초 제안자인 팀 버너스리가 밝힌 적이 있다.

이런 XML의 특징은 수많은 종류의 데이터를 유연하고 자유롭게 기술하는 데 적용할 수 있어서 다양한 용도로 응용할 수 있으며, 인터넷으로 연결된 시스템끼리 쉽게 식별 가능한 데이터를 주고받을 수 있게 된다. 게임 모드 등을 시도해 봤다면 설정파일이 XML로 된 것을 본 경험이 있을 것이다.

XML 문서 작성 시 주의해야 할 점은 예약 문자 처리이다. <, >, &는 XML tag 표시와 entity를 표시하는 XML 예약문자로, 예약 문자가 포함된 XML 을 parsing 하는 경우 "not well-formed (invalid token)" Exception을 발생시킨다. XML 예약문자와 특수문자 리스트

XML을 Python ElementTree를 사용해서 Parsing할때 몇 가지를 유의해야 한다. XML 파일안의 Comment가 유지가 안되거나 한글이 깨지는 경우가 있으나 이는 parser() 와 write() 함수를 조금 수정하면 가능하다sample code.

둘 다 모두 실제 구현체가 아닌 인터페이스 수준으로 느슨하게 정의되어 있다. 그래서 프로그래밍 언어/플랫폼 별로 실제 사용 방법이 조금씩 다를 수 있다. XML이 초기에 널리 퍼진 이유 중 하나는, 거의 웬만한 언어에서 기본으로 지원하는 구조화된 데이터를 읽는 기본 API 보다 훨씬 복잡한 형태의 구조화된 데이터를 읽고 쓰는데 매우 편리했기 때문이다. 지금은 웹 관련 한정으로 JSON이 더 많이 쓰이고 있다.

또한 SAX 파서는 내결함성을 갖게 만들 수 있어 일부 손상된 XML도 읽어서 처리할 수 있다.

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 파일이 있다.

구글맵스는 지도 편집 정보를 KML 파일에 저장한다. XML에서 파생되어 XML의 문법 규칙을 따르는 구글지도 KML은, 구글맵 및 기타 응용 프로그램에서 쓰이는 XML 기반의 마크업 언어의 스키마이며, 지형 정보(Annotation)를 모델링하고 표현하는 역할을 한다. KML 공식 문서, 기본 이론

원래는 웹에서 사용할 목적으로 만들었는데, 웹환경이 아닌 일반 TCP/IP 네트워크 통신을 할 때에도 점점 사용빈도가 늘어나고 있는 추세이다. 디지털 기반의 네트워크 통신을 할 때 송신자와 수신자간에서는 서로 주고받는 데이터 패킷을 비트 단위로 정확하게 맞춰줘야 문제가 생기지 않는데, 이 비트단위 데이터 통신에 하도 불확실성이 많아서...가장 큰 불확실성은 사람이 만든 버그 또한 데이터 패킷단위 전송시 애플리케이션의 개발기반, 구동 환경에 따라 이런저런 잔처리가 많이 들어간다.[1]

그래서 요즘은 아예 XML로 데이터를 주고받는다. 이렇게 하면 최소한 패킷 사이즈가 안 맞아서 발생하는 버그는 줄일 수 있다. 그리고 이렇게 만든 프로그램은 XML로 데이터를 주고받기 때문에 웹확장성도 덤으로 갖게된다.

다른 컴퓨터 사이에 정보를 주고 받는 웹 서비스는 서버에 데이터를 요청하면 기본적으로 결과가 XML로 리턴이 된다. 구글맵 API의 경우도 XML로 데이터를 전달받을 수 있다. 아래 링크를 클릭하면 구경해볼 수 있다.
구글맵 쿼리 테스트

이러한 것이 아닌, 요청과 응답을 XML에 기반하여 제정된 표준으로 XML-RPC와 SOAP이라는 프로토콜이 존재한다. 처음에는 인터넷 상에서 사용할 것을 목적으로 만들었지만, 운용하는 데 생각보다 까다롭고 부담이 많이 되기 때문에 지금은 보수적인 기업 환경이 아니면 보기 힘들다. 현대 기술에 조금이라도 관심이 있는 기업들은 이 무겁디 무거운 XML-RPC 프로토콜 따위는 집어치우고 훨씬 가벼운 REST API를 사용한다. 둘의 근본적인 차이라면 XML-RPC는 요청을 보낼 때 반드시 성공하도록 사전에 줄 수 있는 정보는 사소한 것까지 다 준다는 개념이고 REST API는 반드시 필요한 정보만 보내고 받는 쪽이 그걸 잘 해석할 수 있다고 믿는 대신 실패를 당연하게 생각하는 개념이다.

다만 JavaScript에서는 여러 모로 취급이 불편하고, 실제 데이터 양에 비해서 엄청난 덩치를 자랑하기 때문에[2] JSON이라는 포맷을 따로 만들었을 정도. 단 이것은 웹 브라우저와 직결되는 환경 한정이다. 애초에 JavaScript 사용 빈도 자체가 웹 브라우저 상에서 사용되는 경우가 가장 많으니까.

그러나 이러한 장점이 있는 대신, XML이나 JSON은 공통된 단점이 있으니, 기본적으로 둘 다 문자열에 기반한 것이고, 실 데이터에 비해 오버헤드가 많으며, 메모리 상에 들어있던 데이터를 XML이나 JSON으로 변환(Serialization, Marshalling)하여 전송하고, 다시 이렇게 전송받은 XML 이나 JSON 데이터를 메모리에 복원(Deserialization, Unmarshalling)시키는 오버헤드가 크다. 네트워크 트래픽에 대해선 압축 전송으로 극복할 수 있지만 어쨌든 받은 뒤에는 그 압축을 풀어야 하니까 근본적인 문제는 해결되지 않는다.

어쩌다 한 번 이러한 방식으로 동작하는 프로그램을 운용하는 경우에는 별 문제가 없지만, 1초에도 수십 번 이상 이러한 요청을 받아서 처리하여 결과를 돌려주는 서비스를 운용할 때에는 꽤 문제가 되며, IBM 같은 곳에서는 이러한 변환 작업용 전용 가속 장비를 제작하여 기업용으로 판매할 정도이다. 어떻게든 이러한 문제점을 극복해 보고자 아예 Efficient XML Interchange(EXI)라고 하는 Binary XML 까지 등장했다.[3] 물론 이 정도로 데이터 오버헤드가 문제가 되면 전용 바이너리 포맷을 개발하는 게 보통이다.

DOI 주소를 만들 때에도 사용되고 있다. 취급이 불편하고 부여하기가 부담스럽기는 매한가지.

이것을 응용해서 피처폰에 서비스를 제공한것이 WAP.