XPointer Framework

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] 에서 정의된 이름공간 접두어를 관련된 이름공간 이름으로 지정하는 것.

3.1 문법

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

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

XPointer Framework 문법

위의 생성 규칙에서 보듯이, 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 이다.

[정의: 오직 다음과 같은 조건을 만족하는 경우 (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 에서 결정된다.]

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 은 LocalPart 와 namespace 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/namespace 는 xml 이라는 prefix 로 지정되어 있다. 이것은 다른 prefix 로 지정되어서는 안된다.

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

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

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

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 에 문자열이 포함될 수 있다.

string-range(//P,"my favorite smiley :-)")

xpointer(string-range(//P,"my favorite smiley :-^)"))

#xpointer(string-range(//P,"my favorite smiley :-^)"))

#xpointer(string-range(//P,%22my%20favorite%20smiley%20:-%5E)%22))

#xpointer(string-range(//P,"my favorite smiley :-^)"))

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

id('résumé')

xpointer(id('résumé'))

#xpointer(id('résumé'))

#xpointer(id('r%C3%A9sum%C3%A9'))

#xpointer(id('résumé'))