By 노먼 월시(Norman Walsh)
HTML이나 SGML을 잘 안다면, XML 문서가 이와 유사함을 알 수 있을 것이다. 간단한 XML 문서를 예제 1에 소개했다.
예제 1. 간단한 XML 문서
Say goodnight ,
Gracie.
Goodnight,
Gracie.
|
몇 가지 알아야 할 사항을 소개한다:
- XML 문서는 와 같은 처리 명령으로 시작하는데, 이것이 바로 XML 선언(XML declaration)이다[Section 2.8]. XML 선언을 반드시 표기할 필요는 없지만, 이는 XML 문서임을 명백히 나타내 주고 저작된 XML 버전을 표시해 준다.
- 문서 형 선언(DTD: document type declaration)은 없다. SGML과 달리 XML은 문서 형 선언이 필요하지 않다. 하지만 문서 형 선언은 있어도 상관없으며, 모호함을 피하기 위해 선언이 필요한 경우도 있다.
- 빈 엘리먼트(empty element)(예제 1의 )는 수정된 구문을 가진다[Section 3.1]. 문서의 대다수 엘리먼트는 컨텐츠의 래퍼(wrapper)인데 반해, 빈 엘리먼트는 무언가가 있다는 표시일 뿐이다(수평줄을 나타내는 HTML의
태그나, 교차 참조를 나타내는 DocBook의 태그 등을 예로 들 수 있다). 수정된 구문의 닫는 태그 />는 엘리먼트가 비어 있고, 매치되는 종료 태그가 필요 없는 XML 문서를 처리하는 프로그램이라는 뜻이다. XML 문서에는 문서 형 선언이 필요 없기 때문에, 이러한 단서가 없다면 종료 태그가 필요 없는 경우인지, 혹은 실수로 종료 태그를 쓰지 않은 것인지 XML 파서(parser)가 알아 낼 수 없다.
- XML은 EMPTY로 선언된 엘리먼트와 단지 컨텐츠가 없는 엘리먼트 간에 차이가 별로 없다. 그래서 XML에서는 위의 두 경우 모두 빈 엘리먼트 태그 구문을 사용하는 것이 전혀 이상하지 않다. 물론 처럼 빈 엘리먼트에 시작 태그(start-tag)/종료 태그(end-tag)를 써 줘도 된다. 하지만 상호운용성(interoperability)이라는 측면에서 볼 때, EMPTY로 선언된 엘리먼트에는 빈 엘리먼트 태그 구문을 사용하는 것이 낫다.
XML 문서는 마크업과 컨텐츠로 구성되며, 마크업은 다시 엘리먼트, 엔티티 참조, 각주, 처리 명령, 마크된 섹션, 문서 형 선언의 6가지로 나뉜다. 지금부터는 이러한 마크업의 개념을 소개한다.
엘리먼트
엘리먼트는 마크업에서 가장 자주 나타나는 형식이다. "<>”으로 한계를 정하며, "<>”안에 있는 내용의 속성을 나타낸다. 위에서 살펴 본 것처럼, 어떤 엘리먼트는 비어 있을 수도 있는데, 이 때는 "<>”안에 아무 내용도 없다. 엘리먼트가 비어 있지 않다면,
와 같은 시작 태그로 시작해서, 와 같은 종료 태그로 끝난다.
속성
속성은 엘리먼트 이름 다음의 시작 태그 안에 있는 이름-값 쌍을 말한다.
예를 들면,
위는 "preface"라는 값을 갖는 속성층(attribute class)의 div 엘리먼트이다. XML에서는 모든 값에 인용 부호가 필요하다.
엔티티(entity) 참조
문서에 마크업을 도입하기 위해서는 마크업이 시작되었음을 알리는 문자를 써 줘야 한다. 한 예로, 열기 태그(<)는 엘리먼트가 시작하거나 끝났음을 알려 준다. 그런데 이러한 문자를 컨텐츠로 삽입할 때에는 다르게 표기해야 할 것이다. 이러한 경우 XML에서는 엔티티를 사용해서 특별한 문자임을 나타낸다. 자주 반복되거나 다양한 텍스트를 나타낼 때, 그리고 외부 파일의 내용을 포함할 때에도 엔티티를 사용한다.
엔티티는 고유한 이름이 있어야 한다. 사용자의 고유한 엔티티 이름을 정하는 문제는
엔티티 선언 섹션에서 논의하기로 하자. 엔티티를 사용하려면, 이름에 의해 엔티티를 참조하기만 하면 된다. 엔티티 참조는 앰퍼샌드(&)로 시작해서 세미콜론(;)으로 끝난다.
예를 들어 lt 엔티티는 철자 그대로의 <를 문서에 삽입한다. 그래서 XML 문서에서 문자열
는 로 나타난다.
엔티티 참조의 특별한 형태인 문자 참조(character reference)[Section 4.1]는 문서에 임의의 유니코드(Unicode) 문자를 삽입한다. 이는 키보드로 바로 입력할 수 없는 문자를 입력하기 위해서 개발된 것이다.
문자 참조는 두 가지 형태로 나타난다. ℞와 같은 10진법 참조나, ℞와 같은 16진법 참조가 그것이다. 두 가지 형태 모두 유니코드(표준 Rx 규정 기호)의 문자 번호 U+211E를 참조한다.
각주
각주는 로 끝난다. 각주에는 문자열 --만 빼면 모든 데이터를 넣을 수 있으며, 문서 내 마크업 사이 어느 곳에나 각주를 넣을 수 있다.
각주는 텍스트가 아니므로 XML 프로세서가 각주를 애플리케이션에 전달할 필요가 없다.
처리 명령
처리 명령(PIs)은 애플리케이션에 명령을 제공하는 비상수단이다. 각주와 마찬가지로 처리 명령도 텍스트의 일부는 아니지만, XML 프로세서가 처리 명령을 애플리케이션에 전달해 주어야 한다.
처리 명령에는 와 같은 형식이 있다. PI 목표(PI target)라고 불리는 네임(name)은 애플리케이션에 PI를 알려 준다. 애플리케이션은 인식한 목표만 처리하며 다른 PI는 모두 무시해 버린다. PI 목표를 따르는 데이터는 선택적이며, 목표를 인식해야 하는 이유도 애플리케이션 때문이다. PI에서 사용하는 네임은 공식적으로 표식(notation)이라고 한다.
xml로 시작하는 PI name은 XML 표준화를 위해 약속한 것이다.
CDATA 섹션(CDATA Sections)
CDATA 섹션은 파서(parser)가 대부분의 마크업 문자를 무시하도록 한다.
XML 문서의 소스 코드를 생각해 보자. XML 파서가 마크업으로 인식하는 문자(예를 들면, < 와 &)가 생길 수 있다. 이러한 상황을 피하기 위해 CDATA 섹션을 사용한다.
섹션이 시작되는 사이의 모든 문자 데이터는 아무런 통역 없이, 바로 애플리케이션으로 전달된다. 엘리먼트, 엔티티 참조, 각주, 그리고 처리 명령을 인식하지 않고, 이러한 것을 구성하는 문자는 철자 그대로 애플리케이션에 전달된다.
CDATA 섹션에 입력할 수 없는 유일한 스트링은 ]]>이다.
문서 형 선언(Document Type Declarations)
XML의 여러 가지 선언(Declaration)이 XML 규약(Specification)의 많은 부분을 차지한다. SGML을 다뤄 본 적이 있다면, 이 선언이 SGML DTD(문서 형태 정의)와는 다르다는 것을 알게 될 것이다. SGML DTD를 본 적이 없으면, 그 차이를 못 느낄 수도 있다.
XML의 큰 장점 중 하나는 사용자만가 직접 태그 이름을 만들 수 있다는 것이다. 하지만 특정 애플리케이션용으로 사용할 때에는 태그가 아무렇게나 생성된다는 것은 별 의미가 없다. 다음은 앞에서 소개한 예제 1이다. 그다지 의미 있는 문서는 아니다.
Goodnight,
Gracie
Say goodnight ,
Gracie.
|
위 예제에는 어떠한 정보도 없다. 아무 의미가 없는 것이다.
하지만 구문적 측면에서 보면 위 XML 문서에는 전혀 하자가 없다. 즉 의미 있는 문서가 되려면, 그리고 스타일 시트나 이를 처리할 애플리케이션을 작성하고 있다면, 순서와 태그 중첩에 어느 정도 제약을 가해야 한다. 이러한 제약을 표현하는 것이 바로 선언이다.
좀더 일반적으로 말해서, 선언을 해 줌으로써 문서는 메타 정보의 내용에 대해 파서(parser)와 의사소통할 수 있다. 메타 정보에는 순서와 태그 중첩, 속성 값, 그리고 속성 값의 유형과 디폴트, 참조하는 외부 파일명(XML 포함 유무에 상관없음), 참조하는 외부 데이터 형식(XML 아님), 엔티티(entity) 등이 포함된다.
XML 선언에는 요소 유형 선언, 속성 리스트 선언, 엔티티 선언, 그리고 표시 선언의 4가지 선언이 있다.
요소 유형 선언(Element Type Declarations)
요소 유형 선언[Section 3.2]은 요소명과 요소에 포함되는 내용의 특성을 나타낸다. 다음이 한 예이다.
이는 oldjoke의 요소를 선언한 것이다. 컨텐츠 모델은 요소명(element name) 뒤에 나오며, 요소에 들어갈 내용을 한정한다. 위의 경우에는 oldjoke에 burns와 allen이라는 요소는 반드시 나타나야 하고, applause는 나타나거나 나타나지 않아도 된다. 요소명 사이에는 쉼표(,)로 구분되어 있는데, 여기에 나타난 순서대로 요소명이 나타나야 한다. burns 뒤의 +는 burns이 한 번 이상 나타나는 요소라는 뜻이다. applause 뒤의 ?는 applause가 선택적이라는 뜻이다(생략하거나 한 번 나타난다). allen처럼 아무런 구두점이 없으면 한 번만 나타난다.
위의 burns, allen, applause를 비롯해 다른 요소를 선언해 주면, XML 프로세서가 문서의 유효성도 검사할 수 있다.
요소명에 덧붙이는 특별한 기호인 #PCDATA는 문자 데이터를 나타낸다. PCDATA는 parseable character data, 즉 파싱할 문자 데이터라는 뜻이다.
요소만 있으면 요소 컨텐츠(element content)라고 한다[Section 3.2.1]. 요소와 #PCDATA를 모두 포함하는 요소는 혼합 컨텐츠(mixed content)라고 한다[Section 3.2.2].
예를 들면, burns에 대한 정의는 다음과 같다.
세로선(|)은 #PCDATA와 quote의 관련성을 나타내며, 별표(*)는 이 내용이 선택적이라는 것(나타나지 않거나, 여러 번 나타남)을 나타낸다. 이에 따르면 burns에는 문자가 하나도 나타나지 않거나 여러 번 나타나며, 인용 태그가 순서에 상관없이 나타날 것이다. 혼합 컨텐츠 모델은 다음의 형태를 따른다. #PCDATA가 맨 앞에 위치하며, 모든 요소 사이에는 세로선이 있으며, 전체 그룹은 선택적으로 되어야 한다.
다른 두 가지 컨텐츠 모델도 가능하다. EMPTY는 요소에 아무 내용이 없다(따라서 종료 태그도 없다)는 뜻이며, ANY는 모든 내용이 다 가능하다는 뜻이다. ANY 컨텐츠 모델은 문서를 변환할 때 유용하지만, 문서를 처음 작성할 때에는 무조건 피하는 것이 좋다. 이 요소에 기록하는 모든 컨텐츠를 사용할 수 없도록 만들기 때문이다.
다음은 예제 1에 요소 선언을 해 준 것이다.
예제 2. Old Jokes의 요소 선언
속성 리스트 선언(Attribute List Declarations)
속성 리스트 선언[Section 3.3]은 어떤 요소가 속성을 가지며, 가진다면 어떤 속성인지, 속성 값과 디폴트 속성 값은 얼마인지를 나타내 준다. 전형적인 속성 리스트 선언은 다음과 같다.
이 예제에서 oldjoke 요소에는 세 가지 속성이 있다. ID이며 반드시 필요한 name, 문자열(문자 데이터)이며 반드시 필요하지는 않는 label, 그리고 status는 funny 혹은 notfunny 중 하나로 나타나며, 디폴트는 funny로 되어 있다.
선언에 있는 각각의 속성은 이름, 유형, 디폴트 값의 세 가지 부분으로 나뉜다.
이름에는 약간의 제약이 있긴 하지만[Section 2.3, production 5], 사용자가 원하는 것으로 하면 된다. 하지만 같은 요소에 다른 이름을 부여해서는 안된다.
속성 유형에는 6가지가 있을 수 있다.
- CDATA
- CDATA 속성은 문자열로, 어떤 텍스트도 가능하다. 하지만 CDATA 속성과 CDATA 섹션은 아무 관련이 없으니, 혼동하지 않도록 하자.
- ID
- ID 속성 값은 이름이다[Section 2.3, production 5]. ID는 문서의 고유한 요소를 나타내기 때문에, 문서에서 사용되는 모든 ID 값은 서로 달라야 한다. 그래서 요소는 하나의 ID 속성만을 가질 수 있다.
- IDREF 혹은 IDREFS
- IDREF 속성 값은 문서의 다른 요소에 대한 ID이다. IDREFS 속성은 여러 개의 IDREF 값인데, 서로 다른 IDREF는 여백으로 구분한다[Section 2.3, production 3].
- ENTITY 혹은 ENTITIES
- ENTITY 속성 값은 하나의 엔티티 이름이다(아래의 엔티티 선언에 관한 부분을 참조하자). ENTITIES 속성 값은 여러 개의 엔티티 이름이며, 서로 다른 ENTITY 사이에는 여백을 줘서 구분한다.
- NMTOKEN 혹은 NMTOKENS
- 이름 토큰(Name token) 속성은 문자열 속성의 제한된 형식이다. NMTOKEN 속성은 대개 하나의 단어로 구성되지만[Section 2.3, production 7], 단어에 제약은 없으며, 다른 속성이나 선언과 일치시키지 않아도 된다. NMTOKENS 속성 값은 여러 개의 NMTOKEN 값을 포함하며, 서로 다른 NMTOKEN 사이는 여백으로 구분한다.
- 이름 리스트
- 속성 값은 이름의 특정 리스트에서 불러오게 지정할 수 있다. 선언에 나타날 수 있는 값이 명백히 열거(enumerate)되기 때문에, 열거형 값(enumerated type)으로 불린다. 또한 이름이 표시 이름(notation name)과 일치하도록 지정할 수도 있다(아래의 표시 선언에 관한 부분을 참조하자).
속성의 디폴트 값(default values)에는 다음과 같은 4가지가 있다.
- #REQUIRED
- 이 속성은 반드시 속성 값을 적어 줘야 한다.
- #IMPLIED
- 속성 값을 가져도 되고 안 가져도 되면, 디폴트 값이 필요 없을 경우에 사용한다. 값을 지정해 주지 않으면 XML 처리기에서 이를 처리하지 않는다.
- "value"
- 속성에는 디폴트로 값이 주어진다. 문서의 각각의 요소에 속성 값이 필요 없는 경우, 그리고 속성 값을 빠뜨린 경우, 디폴트 값을 가진다.
- #FIXED "value"
- 속성 값을 고정시킬 수도 있다. 이럴 때에는 속성이 필요하지는 않지만, 속성을 나타내면 속성 값도 함께 나타내 줘야 한다. 속성 값을 나타내 주지 않으면, 디폴트 값으로 되 버리기 때문이다. 요소에 의미를 부여하기 위해 Fixed 속성 값을 사용하기도 한다. 이에 대한 자세한 논의는 주제를 벗어나므로 여기에서는 생략한다. XLink 스펙(XLink specification)에서 Fixed 속성의 몇 가지 예제를 볼 수 있다.
XML 처리기는 속성 값에 대해 속성 값 정규화(normalization)[Section 3.3.3]를 수행한다. 참조한 문자로 문자 참조를 대체하며, 엔티티 참조는 (계속) 리졸브(resolve)되며, 여백은 정규화(normalize)된다.
엔티티 선언(Entity Declarations)
엔티티 선언[Section 4.2]을 하면, 이름과 내용을 연결할 수 있다. 이러한 구조는 일반 텍스트, 문서 형 선언, 혹은 텍스트나 바이너리 데이터를 포함한 외부 파일 참조가 된다.
예제 3에 엔티티 선언 몇 가지를 들었다.
예제 3. 엔티티 선언
엔티티 선언에는 4가지가 있다.
- 내부 엔티티(Internal Entities)
- 내부 엔티티[Section 4.2.1]는 이름과 문자 그대로의 텍스트 문자열을 연결해 준다. 예제 3의 첫째 엔티티는 내부 개체 선언이다.이로써 문서 내 ATI라고 쓰여진 부분은 모두 ArborText, Inc.를 의미하게 된다. 내부 엔티티 선언은 자주 등장하거나, 새로운 버전으로 변경하려는 텍스트에서 유용하게 사용된다.
내부 엔티티는 다른 내부 엔티티에 대한 참조를 포함할 수도 있지만, 다른 내부 엔티티를 자주 참조하면 에러가 나타난다.
XML에 미리 정의되어 있는 내부 엔티티도 있다.
엔티티 참조 문자
< <
> >
& &
' "
" "
|
- 외부 엔티티(External Entities)
- 외부 엔티티[Section 4.2.2]는 이름과 다른 파일의 내용을 연결해 준다. 외부 엔티티를 사용하면, XML 문서에서 다른 문서 형식을 참조할 수 있는데, 외부 엔티티에는 텍스트나 바이너리 데이터가 모두 포함될 수 있다. 텍스트 문서를 포함하면, 외부 파일의 내용은 참조한 위치에 삽입되어 참조 문서의 일부로 파싱된다. 바이너리 데이터는 파싱되지 않으며 속성으로 참조만 된다. 바이너리 데이터는 숫자와 다른 XML 문서의 내용을 참조할 때 사용된다.
예제 3의 둘째와 셋째 엔티티는 외부 엔티티이다.
이로써 boilerplate는 개체 참조 위치에 있는 file /standard/legalnotice.xml 파일을 의미하며, XML 처리기는 이 위치에 /standard/legalnotice.xml 파일이 있는 것처럼 내용을 파싱한다.
ATIlogo 엔티티 역시 외부 개체이지만, 이번엔 바이너리 데이터이다. ATIlogo 엔티티는 ENTITY(혹은 ENTITIES) 속성 값(그래픽 요소 등에서)으로만 사용된다.
- 매개 변수 엔티티(Parameter Entities )
- 매개 변수 엔티티는 DTD에만 나타난다. 매개 변수 선언은 선언에서 이름 앞에 % (퍼센트-여백)를 써 주면된다. % 기호는 & 대신 매개 변수 엔티티를 참조할 때 사용되하도 한다. 일반 엔티티 참조는 바로 적용이 되지 않는 반면, 매개 변수 엔티티 참조는 문서 형 선언으로 바로 적용되어, 참조한 텍스트는 선언의 일부가 된다. 매개 변수 엔티티는 문서의 바디(body)에서는 인식되지 않는다.
예제 2의 요소 선언을 다시 보면, 내용 모델이 같다는 것을 알게 된다.
위에서는 이 두 요소가 우연히 비슷한 정의를 내리게 되었기 때문에 두 요소가 같다고 했는데, 의미론적으로도 같은 요소로 만들려면 매개 변수 엔티티로 내용 모델을 정의하면 된다. 그러면 매개 변수 엔티티를 사용하는 이점이 배가 된다. 우선 내용을 알 수 있는 이름을 부여할 수 있으며, 요소 선언을 업데이트할 때, 내용 모델 중 일부만을 변경할 수도 있다. 그러면 나머지 부분은 그대로 두어도 되는 것이다.
표시 선언(Notation Declarations)
표시 선언[Section 4.7]은 외부 바이너리 데이터의 특정 유형을 나타낸다. 이 정보는 처리 애플리케이션으로 전달되어 작업하게 된다. 다음은 표시 선언의 한 예이다.
문서 형 선언을 해야 합니까?
위에서 살펴보았듯이, XML 문서는 문서 형 선언 없이도 처리된다. 하지만 문서 형 선언을 반드시 해야 하는 경우도 있다.
- 저작 환경
- 저작 환경에서는 문서의 내용 모델을 이해하고 적용하기 위해 대부분 문서 형 선언을 읽고 처리해야 한다.
- 디폴트 속성 값
- XML 문서가 디폴트 속성 값을 필요로 하는 경우에는, 최소한 문서의 일부는 처리되어 올바른 디폴트 값을 가져야 한다.
- 여백 처리
- 요소 내용에서와 혼합 내용에서의 여백의 의미는 서로 다르다. DTD를 하지 않으면, 프로세서가 이의 차이점을 인식할 수 없어서 모든 요소가 혼합 내용으로 인식된다. 이에 대한 자세한 내용은 이 글의 뒷부분에 나오는 여백 처리 부분을 보기 바란다.
데이터베이스에서 바로 생성되는 데이터와는 달리, 사용자가 만들어서 편집하는 애플리케이션의 경우에는 DTD를 해야만 모든 구조를 확실히 할 수 있다.
문서 형 선언
문서 형 선언은 문서의 맨 앞에 위치하는데, 명령 처리와 각주가 그 앞에 올 수도 있다[Section 2.8].
문서 형 선언은 문서의 최상위 요소(root element)를 알려 주며, 부가적인 선언이 더 들어갈 수 있다. 모든 XML 문서는 하나의 최상위 요소를 가지며, 이 최상위 요소는 문서의 모든 내용을 포함한다. 외부 서브세트(subset)라고 불리는 외부 DTD에서, 혹은 문서 내에서 부가적인 선언을 할 수 있다.
위의 예제는 외부 DTD, dbook.dtd를 참조하며, 내부 서브세트의 ulink의 요소와 속성 선언을 포함한다. 이 경우에 ulink는 XLink 규약의 단순 링크를 나타낸다.
내부 서브세트에서 선언한 것이 외부 서브세트에서 선언한 것보다 우선한다. XML 처리기는 외부 서브세트보다 내부 서브세트를 먼저 읽어 들이기 때문이다.
XML 처리기가 전체 문서 형 선언(내부 서브세트와 외부 서브세트)을 읽어야만 유효한 문서인지 알 수 있다. 하지만 일부 애플리케이션에서는 유효성 검사가 필요하지 않기 때문에, 처리기가 내부 서브세트만 읽어도 무방하다. 위의 예제에서는 유효성 검사를 해 주지 않아도 되며, 문서 형 선언을 읽어야 하는 이유가 ulink가 가리키는 것을 이해하기 위해서라면, 내부 서브세트만 읽으면 된다.
독립적인 문서 선언과 이러한 정보를 공유할 수도 있다[Section 2.9]. standalone="yes" 혹은 standalone="no"로 나타나는 독립적인 문서 선언은 XML 선언 내에서 이루어진다. yes는 내부 선언만 처리하면 된다는 뜻이고, no는 내부와 외부 선언 둘 다를 처리해야 한다는 뜻이다.
다른 마크업 관련 문제
마크업과 관련해 고려해야 할 다른 문제도 있다. 즉 여백 처리, 속성 값 정규화, 그리고
어떤 언어로 문서를 작성했는가 등이다.
여백 처리
여백 처리[Section 2.10]는 다소 미묘한 문제다. 다음과 같은 컨텐츠를 보자.
여백(와 사이에 삽입된 빈 줄)에 어떤 의미가 있는가?
아무 의미도 없다.
하지만 정말로 의미가 없는 것인지는 두고 봐야 한다. 여기에서는 해당 요소의 컨텐츠 모델을 알아야만 여백이 의미가 있는지 결정할 수 있다. 여백은 혼합 컨텐츠에서는 의미를 가지며, 요소 컨텐츠에서는 아무 의미도 없다.
XML 처리기는 애플리케이션에 도달할 때까지 마크업이 아닌 모든 문자를 처리해야 한다는 규칙이 있다. 처리기가 유효성을 검사하는 것이라면[Section 5.1], 의미 있는 여백 문자는 어떤 것인지 애플리케이션에 알려야 한다.
특별한 속성인 xml:space는 의미가 있는 여백이라는 것을 나타내 준다. xml:space="preserve"를 써 주면, 이 요소 내(그리고 xml:space를 리셋하지 않는 하위 요소 내) 모든 여백이 의미가 있게 된다.
xml:space에는 preserve와 default 값만이 있다. default 값은 디폴트로 처리되어야 한다는 뜻이다. DTD에서 xml:space는 preserve와 default 값만이 있는 열거형(enumerated type) 속성이다.
여백 처리에서 마지막으로 알아야 할 것은, 파싱된 텍스트에서 XML 처리기가 문장의 마지막에 있는 마커(marker)를 하나의 라인피드(line feed) 문자로 정규화해야 한다는 것이다(&#A;) [Section 2.11]. 문서를 저작하는 사람은 이 부분을 많이 간과해 버리지만, 이렇게 해 주면 다른 플랫폼으로 이식하는 데 발생하는 문제를 피할 수 있다.
속성 값 정규화
XML 처리기는 속성 값 정규화를 한다[Section 3.3.3]. 그래서 참조된 문자가 문자 참조를 대신하게 되면, 엔티티 참조는 (계속) 리졸브되며, 여백은 정규화된다.
언어 식별
XML에서는 xml:lang[Section 3.12] 속성으로 언어를 식별할 수 있어서, 문서 처리 애플리케이션은 문서가 어떤 언어로 쓰여졌는지 알 수 있다. xml;lang 속성은 애플리케이션 사이에 정보를 규격화하기 위해서 만들었는데, XML 규약에서도 어떤 언어로 문서를 작성했는지 알 수 있다.
