W3C

XPointer Framework

W3C Recommendation 25 March 2003

현재 버전:
http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
최신 버전:
http://www.w3.org/TR/xptr-framework/
이전 버전:
http://www.w3.org/TR/2002/PR-xptr-framework-20021113/
저자:
Paul Grosso, Arbortext, Inc. <paul@arbortext.com>
Eve Maler, Sun Microsystems <eve.maler@sun.com>
Jonathan Marsh, Microsoft <jmarsh@microsoft.com>
Norman Walsh, Sun Microsystems <Norman.Walsh@Sun.COM>
번역자:
김남형 <pastime@ece.uos.ac.kr>
번역일:
2003-05-10

공식적인 정오표를 포함하는 이 문서의 errata 페이지를 참고하기 바란다.

이 문서는 다음과 같은 비표준적(Non-normative)인 형태로도 이용할 수 있다: XML.

이 명세의 공식적인 버전은 영어로 작성된 문서이다. 비표준적인 번역 문서는 translations 에서 이용가능하다.


개요

이 명세는 XML Pointer Language (XPointer) Framework 를 정의한다. 이는 추가적인 XPointer scheme 명세에 기반을 둔 XML 문서 안의 요소들을 가리키는 확장가능한 시스템을 말한다. 이 framework 은 text/xml, application/xml, text/xml-external-parsed-entity, 혹은 application/xml-external-parsed-entity 타입의 자원들에 대한 부분 식별자(fragment identifier)의 기저로서 사용될 목적으로 만들어졌다. XML 을 기반으로 한 다른 (미디어) 타입들은 자신들만의 부분 식별자 언어를 정의함으로써 이 framework 를 이용하도록 권고하고 있다.

본 문서의 상태

이 절에서는이 문서의 발행 당시 상태(status)에 대해서 설명하고 있다. 이 문서는 다른 문서로 대체될 수 있다. 이 문서 시리즈의 최근 상황은 W3C 에 의해 관리된다.

이 문서는 W3C 의 권고안 (REC) 이다. 즉 W3C 멤버들과 다른 관련된 그룹들의 검토를 거쳤으며 임원회의 승인을 거쳐 W3C 권고안으로 인정되었다. 이 문서는 안정된 버전으로서 다른 문서에서 이 문서를 참고 문헌으로 사용하거나 인용할 수 있다. 권고안을 제정하는 데 있어 W3C 의 역할은 명세에 관심을 끌어들이는 일과 이러한 사항들이 널리 사용될 수 있도록 촉진하는 데 있다. 이를 통해 Web 의 유용성과 상호 운용성은 더욱 높아질 것이다.

이 문서는 W3C XML Linking Working Group 에 의해 XML Activity 작업의 일환으로서 만들어 졌다. 이 문서는 XPointer requirements 문서의 핵심 부분을 제시하고 있으며, XML Media type 을 위한 부분 식별자 문법의 기초적인 (혹은 전체적인) 부분을 나타낼 목적으로 XPointer element() Scheme, XPointer xmlns() Scheme 명세와 함께 제공된다.

이 문서에 관련하여 의견을 제시하는 것은 환영한다. 공개 메일링 리스트인 다음 주소로 의견을 보내주기 바란다. www-xml-linking-comments@w3.org (archive).

이 명세나 관련된 문서인 XPointer element() Scheme, XPointer xmlns() Scheme 에 관련된 정보나 구현 사항등은 Implementation Report 에서 찾아볼 수 있다.

이 문서의 특허권과 라이센스는 W3C policy 를 따르는 XPointer IPR Statement 페이지에서 찾아볼 수 있다.

현재 W3C 권고안과 다른 기술문서 목록은 http://www.w3.org/TR/ 을 참고하기 바란다. W3C 의 발표 문서들은 언제라도 다른 문서로 업데이트되거나, 교체되거나, 폐기될 수 있다.

목차

1 서론
    1.1 표기법
    1.2 용어
2 다른 명세와의 일치
3 언어와 처리방법
    3.1 문법
    3.2 Shorthand Pointer
    3.3 Scheme-Based Pointer
    3.4 Namespace Binding Context
4 문자의 Escaping
    4.1 Escaping 환경
    4.2 Escaping 예제

부록

A 참조문서
    A.1 표준 참조문서
    A.2 비표준 참조문서


1 서론

이 명세는 XML Pointer Language (XPointer) Framework 을 정의한다. 이는 추가적인 XPointer scheme 명세를 이용하여 XML 문서의 특정 부분을 가리킬 수 있는 확장가능한 시스템을 말한다. 이러한 framework 는 text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity 와 같은 Internet media type 을 가지는 자원들에 대한 부분적인 식별자를 제공하는 기반으로서 사용되도록 만들어 졌다. 이밖의 XML 을 기반으로 한 media type 들은 이 framework 을 이용하여 자신들만의 독자적인 부분 식별자 언어를 정의할 것을 권하는 바이다.

XML 을 처리하는 많은 종류의 application 에서는 URI 참조를 통하여 XML 자원들의 내부적인 구조를 접근하는 것이 필요하다. 예를 들어 XML Linking Language [XLink], XML Inclusions [XInclude], Resource Description Framework [RDF], SOAP 1.2 [SOAP12] 와 같은 것들이 있을 것이다. 이 명세에서는 XML 자원에 대한 URI 참조를 이용하는 application 의 타입이나 그러한 프로그램들이 원하는 자원에 관한 정보를 얻은 후의 동작에 관해서는 제한을 두지 않는다.

1.1 표기법

[정의: 이 명세에서 사용된 must, must not, required, shall, shall not, should, should not, recommended, may, optional 이라는 용어는 [RFC 2119] 에서 설명하는 대로 해석되어 진다.]

XPointer Framework 의 형식 문법은 XML 권고안 [XML] 에서 설명하는 단순한 Extended Backus-Naur Form (EBNF) 표기법을 사용하여 제공된다.

1.2 용어

[정의: pointer ]

이 명세를 따르는 문자열. 이 명세는 pointer 의 문법과 의미를 정의한다.

[정의: pointer part ]

해당 scheme 의 정의를 따르는 scheme 이름과 몇몇 pointer 데이타를 제공하는 pointer 의 일부분. XPointer processor 는 하나의 XML 자원 내의 0 개 이상의 하위 자원들을 가리키는 pointer part 를 계산한다.

[정의: scheme ]

scheme 이름과 이 명세에 정의된 사항들을 가지는 특별한 pointer 데이타 형식.

[정의: XPointer processor ]

하나의 XML 자원에 대해 pointer 를 적용하여 하위 자원들을 가리킬 수 잇는 소프트웨어 요소. 이 명세에서는 XPointer processor 의 동작에서 대해서 정의한다.

[정의: application ]

XML 자원들에 접근하기 위해 XPointer processor 를 사용하거나 XPointer processor 와 함께 동작하는 소프트웨어 요소. XPointer 의 사용횟수나 사용법, 이러한 XPointer 를 이용하여 얻어진 자원들에게 적용되는 행동 등은 각 application 들의 연관된 데이타 형식의 정의해 따라 결정된다. (XML 기반인지 아닌지) 예를 들어 HTML [HTML] 웹 브라우저와 XInclude processor 는 둘다 XPointer processor 를 사용하는 프로그램이다.

[정의: error ]

이 명세에서 정의한 문법적인 규칙을 어기거나 pointer 가 하위 자원들을 찾아내지 못한 경우

[정의: namespace binding context ]

XML-namespace [XML-Names] 에서 정의된 이름공간 접두어를 관련된 이름공간 이름으로 지정하는 것.

2 다른 명세와의 일치

이 명세는 framework 을 정의한다; 현재는 XPointer processor 에 대한 최소한의 일치 수준도 정의되어 있지 않다. 따라서 이번 절에서는 어떤 최소한의 일치 수준의 framework 의 부분에 대해서만 요구사항을 정의한다.

XPointer processor 는 application 이 어떤 부분 식별자의 인코딩과 escaping 을 재해석하는 능력에 의존한다. (4 문자의 Escaping 참고)

XPointer processor 의 행동은 XML 자원에서 얻은 정보의 이용가능성에 의존한다. [Infoset] 에서 제공하는 용어로 표현하면, information item 과 property 는 연관되어 있을 것이다. 이러한 item 과 property 의 존재는 일치하는 DTD 나 XML Schema 의 처리에 차례로 의존한다: 일치하는 XPointer processor 는 그러한 처리를 필요로 하지 않을 테지만, 만약 그러한 경우에는 정보의 Shorthand Pointer 처리가 유용하게 사용 것이다. (3.2 Shorthand Pointer 참조)

XPointer processor 를 구현하는 소프트웨어 요소는 반드시 이 XPointer Framework 명세와 이 명세에 관련된 다른 명세를 따라야 하며, XPointer 를 위한 최소한의 일치 수준도 정의해야 한다. 그리고 추가적인 XPointer scheme 에 관한 명세를 따를 수도 있다. XPointer processor 는 다른 추가적인 scheme 명세를 따른 경우 반드시 그것을 문서화 해야 한다. XPointer processing 에 의존하는 명세는 그것이 요구하고 지원하는 scheme 에 관하여 문서화 해야 한다.

이 명세를 따르는 XPointer processor 는 반드시 application 에게 XPointer Framework error 를 보고해야 한다. application 에서 XPointer Framework error 를 보고받았을 때 이를 종료시키거나 어떠한 방식으로든 이를 복구하거나 하는 것은 자유이다.

3 언어와 처리방법

이 절에서는 XPointer Framework 과 이 framework 에 관련된 XPointer processor 의 동작을 설명한다.

XPointer processo 는 입력으로 XML 자원이나 pointer 로 사용될 문자열 (예를 들어, 어떤 자원에 접근하기 위해 사용된 URI 자원의, 역으로 escaping 된, 부분 식별자(fragment identifier)) 을 받아서, 그 자원에 관련된 pointer 를 계산할려고 시도한 뒤, 출력으로 하위 자원에 대한 위치 혹은 error 를 반환한다.

3.1 문법

만약 pointer 로 사용된 문자열이 이 절에서 정의한 문법에 맞지 않으면 error 이다.

심벌 S[XML] 에 정의되어 있다. NCName 라는 심벌과 QName 라는 심벌은 [XML-Names] 에 정의되어 있다.

XPointer Framework 문법
[1]    Pointer    ::=    Shorthand | SchemeBased
[2]    Shorthand   ::=    NCName
[3]    SchemeBased    ::=    PointerPart (S? PointerPart)*
[4]    PointerPart    ::=    SchemeName '(' SchemeData ')'
[5]    SchemeName    ::=    QName
[6]    SchemeData    ::=    EscapedData*
[7]    EscapedData    ::=    NormalChar | '^(' | '^)' | '^^' | '(' SchemeData ')'
[8]    NormalChar    ::=    UnicodeChar - [()^]
[9]    UnicodeChar    ::=    [#x0-#x10FFFF]

위의 생성 규칙에서 보듯이, pointer part 의 끝은 닫는 괄호 ")" 로 표시되며, pointer part 의 시작인 여는 괄호 "(" 에 쌍을 이룬다. 만약 이러한 괄호들이 짝이 맞지 않은 채로 scheme date 안에 존재하려면, 반드시 그 앞에 꺽쇠 (^) 로 escaping 해 주어야 한다. 짝이 맞는 괄호의 escaping pair 도 허용된다. 꺽쇠 그 자체를 표시하기 위해서는 반드시 그 앞에 꺽쇠를 하나 더 붙여서 escaping 해야 한다. (즉, ^^ 가 된다.) 이외의 용도로 꺽쇠를 사용하는 것은 error 이다.

3.2 Shorthand Pointer

shorthand pointer 는 이전에는 barename 이라고 불렸으며, 하나의 NCName 만으로 이루어진다. 이것은 자원의 information set 내에서 최대 한개의 원소를 가리킨다. 특별히, 문서의 순서 상에서 식별자와 첫번째로 매치되는 (어떤 것이든지) NCName 을 말하는 것이다. 원소의 식별자는 다음과 같이 결정된다:

  1. 만약 element information item 이 그 [attributes] 가운데 attribute information item 을 가지고 있다면 그것은 schema-determined ID 가 될 것이고, attribute information item 의 [schema normalized value] 속성의 값에 의해 구분될 것이다.

  2. 만약 element information item 이 그 [children] 가운데 element informaiton item 을 가지고 있다면 그것은 schema-determined ID 가 될 것이고, element information item 의 [schema normalized value] 속성의 값에 의해 구분될 것이다.

  3. 만약 element information item 이 그 [attributes] 가운데 attribute information item 을 가지고 있다면 그것은 DTD-determined ID 가 될 것이고, attribute information item 의 [normalized value] 속성의 값에 의해 구분될 것이다.

  4. element information item 은 externally-determined ID 의 값에 의해서도 식별될 수 있다.

만약 shorthand pointer 의 NCName 에 의해 나타내어 지는 element information item 이 하나도 없다면, pointer 는 error 이다.

주의:

element information item 는 문서 상에서 다음과 같은 여러가지 값들에 의해 복합적으로 나타내어 질 수 있다. DTD-determined IDs, schema-determined IDs, externally-determined IDs. 그런한 문서에서, 협업성(interoperability)이 지원되지 않는다면 특정한 원소에 대한 식별자의 값은 항상 동일하지는 않을 것이다.

[정의: 오직 다음과 같은 조건을 만족하는 경우 (if and only if) element information item 이나 attribute information item 은 schema-determined ID 이다.]

  1. [member type definition][type definition] 속성을 가지며 그 값은 [name]ID 와 같고, [target namespace]http://www.w3.org/2001/XMLSchema 와 같은 경우

  2. [base type definition] 을 가지며, 그 값은 [name][target namespace] 를 가지는 경우

  3. [base type definition] 을 가지며, 그 값은 [base type definition] 를 가지고 그 값은 [name] and [target namespace] 을 가지고, 계속해서 [base type definition] 의 속성을 재귀적으로 따르는 경우

  4. [type definition name]ID 와 같고, [type definition namespace]http://www.w3.org/2001/XMLSchema 와 같은 경우

  5. [member type definition name]ID 와 같고, [member type definition namespace]http://www.w3.org/2001/XMLSchema 와 같은 경우

[정의: attribute information item 이 [type definition] 속성을 가지며 그 값이 ID 와 동일한 경우 (if and only if) attribute information item 은 DTD-determined ID 이다.]

[정의: externally-determined ID 은 원소의 식별자를 나타내는 문자열이며, 그 값은 (이 명세의 범위를 벗어나는 메카니즘을 통해) application 에서 결정된다.]

주의:

shorthand pointer 는 XML-based media type 의 자원에 대해 HTML 부분 식별자와 대체적으로 비슷하게 동작한다. 하지만, 만약 DTD 나 schema 혹은 application 의 고유한 정보 등이 없어서 ID 정보가 없는 경우에는 pointer 는 어떠한 원소도 가리키지 못한다. 더욱 신뢰성있는 원소의 식별을 위한 몇가지 방법들이 있다. 예를 들어 자원을 생성한 사람은 ID 타입의 속성이 존재함을 나타내기 위해 내부적인 DTD 의 부분집합을 사용할 수 있고, pointer 를 생성한 사람은 shorthand pointer 대신 scheme-based pointer 를 사용하거나, 원하는 원소를 다른 방법으로 가리키기 위해 하나 이상의 scheme 을 제공할 수 있다.

주의:

위에서 정의한 내용들은 문서 내에서 element information item 에 의해 구별되는 값이 유일한 값인지 아닌지에 영향을 받지 않는다. 왜냐하면 [XML] 이나 [XMLSchema] 에서 ID 타입에 대해 이러한 사항에 대해 요구하지 않기 때문이다.

3.3 Scheme-Based Pointer

scheme-based pointer 는 하나 이상의 pointer part 로 구성되며 이들은 각각 공백문자 (S) 로 구분될 수 있다. 각 부분들은 scheme name 를 가지며, 괄호안에 scheme 에 해당하는 데이타 (EscapedData) 를 포함한다. 만약 scheme data 내부에 괄호가 들어있다면 그것들은 반드시 쌍을 이루거나 escape 처리 되어야 한다.

다수의 pointer part 가 제공되는 경우, XPointer processor 는 반드시 왼쪽부터 처리해 가야한다. 만약 XPointer processor 가 pointer part 에서 사용된 scheme 을 지원하지 않는 경우에는, 그 부분은 그냥 지나친다. 만약 pointer part 가 어떠한 하위 자원도 가리키지 않는 경우에는, 계속해서 다음의 pointer part 가 계산된다. 첫번째 pointer part 의 계산 결과 하나 이상의 하위 자원을 가리키게 되는 경우 XPointer processor 는 pointer 전체의 결과로 인식하고 계산을 멈춘다. 만약 어떠한 pointer part 도 하위 자원을 가리키지 않는 경우는 error 이다.

다음의 예제에서, 만약 'xpointer' 라는 pointer part 가 알수 없는 것이거나 어떠한 하위 자원을 가리키는 데에 실패한다면, 'element' 라는 pointer part 가 계산될 것이다. 만약 'xpointer' 라는 pointer part 가 하위 자원을 가리킨다면 'element' 라는 pointer part 는 계산되지 않는다.

#xpointer(id('boy-blue')/horn[1])element(boy-blue/3)

scheme name 은 문법적으로, [XML-Names] 에 정의된 생략가능한 Prefix 부분과 LocalPart 부분으로 구성된다. 간략하게 말하면, scheme name 은 LocalPartnamespace binding context 하에서 Prefix 에 대응하는 namespace name 으로 구성된 순서쌍(tuple) 이다. 만약 namespace binding context 가 해당하는 어떤 prefix 도 포함하고 있지 않거나, (namespace name, LocalPart) 의 쌍이 XPointer processor 가 지원하는 scheme name 에 해당하지 않는 경우, pointer part 는 계산되지 않는다.

이 명세는 W3C 권고안에 정의된 추가적인 XPointer scheme 들에 대한 모든 허가되지 않는 scheme name 들에 대해서도 예약해 두고 있다. scheme name 으로 QNames 을 사용하는 것은 다른 XML-based media type 에 대해서도 이 framework 을 이용하여 독자적인 부분 식별자 언어를 정의하도록 하는 확장성있는 일반적인 framework 를 제공한다. XPointer framework 에서 사용되어질 모든 scheme 의 정의는 반드시 (namespace name, LocalPart) 의 쌍으로 구성된 scheme name 을 명시해야 한다.

3.4 Namespace Binding Context

scheme 명세는 scheme name, 원소 이름, 속성 이름 등과 pointer part 에 사용되는 다른 QNames 들의 prefix 를 해석할 목적으로 XML 이름공간 [XML-Names] 의 prefix 를 이름공간의 이름으로 지정할 수 있는 방법을 제공 할 수 있다. 이러한 기능은 질의상에서 scheme 에 의해 명시적으로 예외가 발생되지 않는 한, 이름공간을 지정한 pointer part 보다 오른쪽에 위치하는 모든 pointer part 에게 적용되는 namespace binding context 를 제공한다. 이름공간 지정을 제공하는 scheme 에서는 반드시 이러한 이름공간의 지정이 이후의 pointer part 들에게 영향을 주는 지를 문서화 해야 한다. 모든 scheme 에 대한 문서에서는 그 scheme 이 namespace binding context 를 사용하는지를 반드시 명시해야 한다.

다음의 예제에서 'xmlns' scheme 은 ([XPtrXmlns] 참고) namespace binding context 에 (prefix/namespace name) 의 지정을 추가하는데 사용되었다. XPointer processor 는 이 정보를 img:rect 가 지원가능한 scheme 의 이름을 나타내는지를 확인하는데 사용한다.

#xmlns(img=http://example.org/image)img:rect(10,10,50,50)

초기의 namespace binding context 는 하나의 개체를 가지는 첫번째 pointer part 의 계산보다 우선시된다: xml prefix 는 http://www.w3.org/XML/1998/namespace 의 이름공간에 지정되어 있다. namespace binding context 는 다음 제한사항들의 주체이다. 이러한 제한사항들을 어기도록 시도하는 것은 namespace binding context 상에 아무런 영향을 주지 못한다.

  • xml prefix 는 http://www.w3.org/XML/1998/namespace 의 이름공간에 지정되어 있다. 이것은 다른 이름공간으로 지정되어서는 안된다.

  • 이름공간 http://www.w3.org/XML/1998/namespacexml 이라는 prefix 로 지정되어 있다. 이것은 다른 prefix 로 지정되어서는 안된다.

  • xmlns prefix 는 이름공간으로 지정되어서는 안된다.

  • 이름공간 http://www.w3.org/2000/xmlns/ 는 어떤 prefix 로도 지정되어서는 안된다.

x, m, l 세글자로 시작하는 prefix 는 모두 예약되어 있다. 사용자는 XML 이나 XML 에 관련된 명세에서 정의된 경우를 제외하고 이들 prefix 를 사용하지 말아야 한다.

4 문자의 Escaping

XPointer 의 문자셋은 [Unicode] 이다. 하지만, XPointer 언어는 특정 문자의 인코딩이나 escaping 을 요구하는 URI 참조 [RFC 2396] 환경이나, IRI 참조 [IRI] 환경 하에서 사용되도록 디자인되었다. XPointer 와 XPointer 를 포함하는 IRI 참조는 XML 문서나 외부의 분석된 개체에서 종종 등장하며, 이것은 encoding 이 직접적으로 사용되는 부분이 제한되는 경우 고유한 escaping 이 요구되어 진다. 다른 환경에서도 XPointer 에 적용되는 추가적인 escaping 을 요구할 수 있다. 또한, 특정 문자들은 XPointer 의 처리 중에 특별한 용도로 사용되므로 이러한 문자들을 문자 그대로의 의미로 사용하기 위해서는 escaping 이 필요한다.

4.1 Escaping 환경

다음과 같은 환경에서는 XPointer 에 적용되는 다양한 타입의 escaping 이 요구된다:

A. XPointer-에서 특별히 사용되는 문자의 escaping

3.1 문법 절에서 설명했듯이, 쌍을 이루지 않는 괄호와 꺽쇠는 반드시 escape 처리를 해야 한다.

B. IRI 에서 예약된 문자의 Escaping 과 인코딩

[정의: IRI (Internationalized Resource Identifier) 는 URI 의 문법을 보다 광범위한 [Unicode] 문자들로 확장한 프로토콜 요소 (protocol element) 이다.] IRI 참조는 escape 된 URI 참조의 모든 문자들을 포함하며, 일반적인 의미로 퍼센트 기호 (%) 를 사용할 때는 반드시 escape 처리를 해야 한다. 왜냐하면 퍼센트 기호는 URI 와 IRI 에서 escaping 을 위한 문자로 사용되기 때문이다.

따라서 IRI 참조에 pointer 가 포함된 경우, 퍼센트 기호 (%) 를 사용할 때는 반드시 escape 처리가 되어야 한다. 다른 문자들도 escape 처리될 수 있지만 이를 추천하지는 않는다. 문자들은 다음과 같이 escape 처리 된다:

  1. escape 처리될 각각의 문자는 UTF-8 [RFC 2279] 로 변환된다. (한 바이트 이상이 될 수 있음)

  2. 결과로 나오는 바이트들은 URI escaping 메카니즘에 따라 escape 처리된다. (즉, 바이트의 값이 16진수로 HH 일 때, %HH 로 변환된다.)

  3. 원래의 문자는 결과로 나오는 바이트(들) 로 대체된다.

예를 들어 %%25 가 된다.

C. URI 에서 예약된 문자의 Escaping 과 인코딩

IRI 참조는 URI resolver 를 통해 URI 참조로 변환될 수 있다. ASCII 문자가 아닌 모든 문자와 샵 기호 (#), 퍼센트 기호 (%), 대괄호 ([]) 를 제외한 [RFC 2396] 의 2.4 절에 명시된 금지 문자 들을 포함한 URI 참조에서 허용되지 않는 문자들은 [RFC 2732] 에서 다시 허용되었다. 허용되지 않는 문자들은 다음과 같이 escape 처리된다:

  1. 각각의 허용되지 않은 문자는 UTF-8 [RFC 2279] 로 변환된다. (한 바이트 이상이 될 수 있음)

  2. 결과로 나오는 바이트들은 URI escaping 메카니즘에 따라 escape 처리된다. (즉, 바이트의 값이 16진수로 HH 일 때, %HH 로 변환된다.)

  3. 원래의 문자는 결과로 나오는 바이트(들) 로 대체된다.

D. XML escaping

만약 pointer 가 XML 문서나 외부의 분석된 개체 내에 등장한다면, 사용된 인코딩에서 표현하지 못하는 문자들은 반드시 문자 참조로 escape 처리되어야 하며, XML 처리 상에서 특별한 용도로 사용되는 문자들은 그 문자가 등장한 곳에서 문자 참조나 개체 참조와 같은 적절한 메카니즘으로 반드시 escape 처리 되어야 한다. 이러한 escaping 은 XML 문서나 개체가 분석(parse)될 때 예약된다. URI 참조가 (좀더 일반적인 IRI 참조가 아니라) XML 문서 상에 나타나게 하지 않기를 권고한다. 만약 어떠한 이유로 그것이 불가피하다면, 동일한 escaping 메카니즘이 적용된다.

XPointer processor 에서는 오직 XPointer 에서 특별한 용도로 사용되는 문자 (A) 만을 예약해 두었기 때문에, application 에서는 반드시 pointer 가 의존하는 다른 종류의 인코딩이나 escaping (B, C, D) 을 예약해 두어야 한다. 만약 XPointer processor 에 넘겨진 결과가 이 명세의 XPointer 문법 규칙을 따르지 않는다면, error 이다.

4.2 Escaping 예제

다음의 표는 쌍을 이루지 않는 괄호, 겹따옴표, 공백 등을 포함하는 다양한 XPointer 의 환경하에서는 escaping 을 보여준다. 이 예제는 'xpointer' scheme 을 사용하였으며 ([XPtrXPointer] 참조), 'xpointer' scheme 에서는 scheme data 에 문자열이 포함될 수 있다.

환경 표기
초기의 Scheme Data 최초에 생성된 xpointer scheme data:
string-range(//P,"my favorite smiley :-)")
A. XPointer 이 명세에서 요구한 대로, scheme data 내의 짝을 이루지 않는 괄호를 escape 처리:
xpointer(string-range(//P,"my favorite smiley :-^)"))
B. IRI 참조 내의 Pointer A 와 동일 (escape 처리해야 할 퍼센트 기호 없음):
#xpointer(string-range(//P,"my favorite smiley :-^)"))
C. IRI 참조를 URI 참조로 변환 겹따옴표 (%22), 공백 (%20), 꺽쇠 (%5E) escape 처리:
#xpointer(string-range(//P,%22my%20favorite%20smiley%20:-%5E)%22))
D. XML 문서 내의 IRI 참조 겹따옴포를 XML 에서 정의된 &quot; 개체 참조로 escape 처리 (겹따옴표로 묶인 속성의 값 내에 IRI 참조 내에 pointer 가 등장한다고 가정):
#xpointer(string-range(//P,&quot;my favorite smiley :-^)&quot;))

다음의 표는 다양한 환경 하에서 악센트 문자를 포함하는 XPointer 의 escaping 처리를 보여준다. XML 문서는 "é" 문자를 직접 사용할 수 없는 US-ASCII 로 인코딩 되었다고 가정한다.

환경 표기
초기의Scheme Data 최초에 생성된 xpointer scheme data:
id('résumé')
A. XPointer XPointer (escape 해야할 꺽쇠나 짝을 이루지 않는 괄호가 없음):
xpointer(id('résumé'))
B. IRI 참조 내의 Pointer A 와 동일 (escape 해야할 퍼센트 기호 없음):
#xpointer(id('résumé'))
C. IRI 참조를 URI 참조로 변환 "é" 문자 escape 처리 (%C3%A9):
#xpointer(id('r%C3%A9sum%C3%A9'))
D. XML 문서 내의 IRI 참조 US-ASCII 인코딩으로 표헌; 악센트 문자는 XML 문자 표현방식으로 escape 처리:
#xpointer(id('r&#xE9;sum&#xE9;'))

A 참조문서

A.1 표준 참조문서

Infoset
John Cowan and Richard Tobin, editors. XML Information Set. World Wide Web Consortium, 2001.
RFC 2119
Scott Bradner, RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force, 1997.
RFC 2396
Tim Berners-Lee, Roy Fielding, and Larry Masinter, RFC 2396: Uniform Resource Identifiers. Internet Engineering Task Force, 1995.
RFC 2732
Robert Hinden, Brian Carpenter, and Larry Masinter, RFC 2732: Format for Literal IPv6 Addresses in URL's. Internet Engineering Task Force, 1999.
RFC 2279
François Yergeau RFC 2279: UTF-8, a transformation format of ISO 10646. Internet Engineering Task Force, 1998.
RFC 3023
MURATA Makoto, Simon St.Laurent, and Dan Kohn, RFC 3023: XML Media Types. Internet Engineering Task Force, 2001.
XML
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, and Eve Maler, editors. Extensible Markup Language (XML) 1.0 (Second Edition). World Wide Web Consortium, 2000.
XML-Names
Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999.
XMLSchema
Henry Thompson et al., editors. XML Schema Part 1. World Wide Web Consortium, 2001.
Unicode
The Unicode Consortium The Unicode Standard.

A.2 비표준 참조문서

HTML
Dave Raggett, Arnaud Le Hors, and Ian Jacobs. HTML 4.01 Specification. World Wide Web Consortium, 1999.
IRI
Martin J. Dürst and Michel Suignard Internationalized Resource Identifiers (IRI) Internet draft draft-duerst-iri-01, Internet Engineering Task Force, 2002. Work in progress.
RDF
Dave Beckett, editor. RDF/XML Syntax Specification. World Wide Web Consortium, 2001.
SOAP12
Nilo Mitra et al., editors. SOAP Version 1.2 Parts 0, 1, and 2. World Wide Web Consortium, 2001. Work in progress.
XInclude
Jonathan Marsh and David Orchard, editors. XML Inclusions (XInclude) Version 1.0. Work in progress. World Wide Web Consortium, 2001.
XLink
Steve DeRose, Eve Maler, and David Orchard, editors. XML Linking Language (XLink). World Wide Web Consortium, 2001.
XPtrXmlns
Paul Grosso, Eve Maler, Jonathan Marsh, and Norman Walsh, editors. XPointer xmlns() Scheme. World Wide Web Consortium, 2003.
XPtrXPointer
Steven DeRose, Eve Maler, and Ron Daniel Jr., editors. XPointer xpointer() Scheme. World Wide Web Consortium, 2002. Work in progress.