XML 및 Junos XML 관리 프로토콜 규칙 개요
클라이언트 애플리케이션은 XML 및 Junos XML 관리 프로토콜 규칙을 준수해야 합니다. 클라이언트 애플리케이션의 각 요청은 잘 형성된 XML 문서여야 합니다. 즉, 요청에 인코딩된 정보의 종류에 대해 Junos XML 프로토콜 및 Junos XML 문서 유형 정의(DTD)에 정의된 구조 규칙을 준수해야 합니다. 클라이언트 애플리케이션은 필요한 순서와 법적 맥락에서만 태그 요소를 방출해야 합니다. Junos OS 또는 Junos XML 프로토콜을 변경할 경우 규정을 준수하는 애플리케이션을 보다 쉽게 유지할 수 있습니다.
마찬가지로, Junos XML 프로토콜 서버의 각 응답은 잘 형성된 XML 문서(Junos XML 프로토콜 서버 obeys XML 및 Junos XML 관리 프로토콜 규칙)를 구성합니다.
다음 섹션에서는 Junos XML 관리 프로토콜 규칙을 설명합니다.
요청 및 응답 태그 요소
요청 태그 요소는 디바이스의 현재 상태 또는 구성에 대한 정보를 요청하거나 구성을 변경하기 위해 클라이언트 애플리케이션에서 생성되는 요소입니다. 요청 태그 요소는 CLI 운영 또는 구성 명령에 해당합니다. 태그 내에서 <rpc> 만 발생할 수 있습니다. 요소에 <rpc> 대한 정보는 Junos XML 프로토콜 서버로의 요청 전송을 참조하십시오.
응답 태그 요소는 요청 태그 요소에 대한 Junos XML 프로토콜 서버의 응답을 나타내며 태그 내에서 <rpc-reply> 만 발생합니다. 요소에 <rpc-reply> 대한 정보는 Junos XML 프로토콜 서버 응답 구문 분석 을 참조하십시오.
다음 예는 클라이언트 애플리케이션이 요청 태그를 flag와 함께 <extensive/> 내보내 <get-interface-information> 고 Junos XML 프로토콜 서버가 응답 요소를 반환하는 교환을 <interface-information> 나타냅니다.
이 예는 이 가이드의 다른 모든 요소와 마찬가지로 클라이언트 애플리케이션과 Junos XML 프로토콜 서버 모두에서 방출되는 태그 스트림의 별개의 줄에 있는 각 태그 요소를 보여줍니다. 실제로 클라이언트 애플리케이션은 태그 요소 사이에 새 문자를 포함할 필요가 없습니다. 서버가 이러한 공백을 자동으로 삭제하기 때문입니다. 자세한 내용은 공백, 새 문자 및 기타 공백을 참조하십시오.
오프닝 rpc-reply 태그의 속성에 대한 자세한 내용은 Junos XML 프로토콜 서버 응답 구문 분석 을 참조하십시오. 오프닝 태그의 속성에 xmlns 대한 정보는 Junos XML 프로토콜을 사용하여 운영 정보 요청을 참조하십시오.<interface-information>
요청 태그 요소의 하위 태그 요소
일부 요청 태그 요소에는 하위 태그 요소가 포함되어 있습니다. 구성 요청의 경우, 각 하위 태그 요소는 구성 요소(계층 수준 또는 구성 객체)를 나타냅니다. 운영 요청의 경우, 각 하위 태그 요소는 동등한 CLI 명령을 발행할 때 명령줄에서 제공하는 옵션 중 하나를 나타냅니다.
일부 요청에는 필수 하위 태그 요소가 있습니다. 요청을 성공적으로 하려면 클라이언트 애플리케이션이 요청 태그 요소의 개/마감 태그 내에서 필수 태그 요소를 내보내야 합니다. 어린이 중 어느 것이든 컨테이너 태그 요소인 경우, 각 에 대한 열기 태그는 포함된 태그 요소 앞에 발생해야 하며, 계층 수준에서 다른 태그 요소에 대한 열기 태그 앞에 닫기 태그가 발생해야 합니다.
대부분의 경우 클라이언트 애플리케이션은 컨테이너 태그 요소 내에서 동일한 수준에서 어떤 순서로 발생하는 자식들을 내보낸다. 중요한 예외는 구성 요소를 유형의 다른 요소와 구별하는 식별자 태그 요소가 있는 구성 요소입니다. 식별자 태그 요소는 컨테이너 태그 요소의 첫 번째 하위 태그 요소여야 합니다. 식별자 태그 요소는 구성 요소의 이름을 지정하고 라고 합니다 <name>.
응답 태그 요소의 하위 태그 요소
응답 태그 요소의 하위 태그 요소는 특정 요청에 대해 Junos XML 프로토콜 서버에서 반환한 개별 데이터 항목을 나타냅니다. 자식은 개별 태그 요소(빈 태그 또는 태그 요소 트리플) 또는 하위 태그 요소를 묶는 컨테이너 태그 요소일 수 있습니다. 일부 컨테이너 태그 요소의 경우, Junos XML 프로토콜 서버는 자식을 알파벳 순으로 반환합니다. 다른 요소의 경우, 아이들은 구성에서 생성 한 순서대로 나타납니다.
응답 또는 컨테이너 태그 요소 내에서 발생할 수 있는 하위 태그 요소 집합은 Junos XML API의 이후 릴리스에서 변경될 수 있습니다. 클라이언트 애플리케이션은 Junos XML 프로토콜 서버 출력의 특정 태그 요소의 존재 또는 부재 또는 응답 태그 요소 내 하위 태그 요소 순서에 의존해서는 안 됩니다. 가장 강력한 작업을 위해 예상 태그 요소가 없거나 예기치 않은 태그 요소가 가능한 한 원활하게 존재하도록 처리하는 클라이언트 애플리케이션의 논리를 포함합니다.
공백, 새 문자 및 기타 공백
XML 사양에 따라 Junos XML 프로토콜 서버는 클라이언트 애플리케이션에서 생성된 태그 스트림의 태그 요소 간에 발생하는 공백(공백, 탭, 새 문자 및 공백을 나타내는 기타 문자)을 무시합니다. 클라이언트 애플리케이션은 태그 요소 사이에 공백을 포함할 수 있지만 그렇게 할 필요는 없습니다. 그러나 열거나 닫는 태그 내에 공백을 삽입해서는 안 있습니다. 후보 구성에 대한 변경으로 제출하는 태그 요소의 콘텐츠에 공백이 포함된 경우, Junos XML 프로토콜 서버는 구성 데이터베이스의 공백을 보존합니다.
응답에서 Junos XML 프로토콜 서버는 파일에 저장된 응답의 가독성을 향상시키기 위해 태그 요소 간의 공백을 포함합니다: 새 문자를 사용하여 각 태그 요소를 자체 줄에 배치하고, 부모에 비해 하위 태그 요소를 오른쪽에 둔 공간입니다. 클라이언트 애플리케이션은 공백을 무시하거나 폐기할 수 있습니다. 특히 클라이언트 애플리케이션이 사용자들이 나중에 검토를 위해 응답을 저장하지 않는 경우. 그러나 태그 스트림을 구문 분석할 때 특정 위치에 공백이 있는지 여부에 따라 달라서는 안 됩니다.
XML 문서의 공백에 대한 자세한 내용은 월드 와이드 웹 컨소시엄(W3C), 확장형 마크업 언어(XML) 1.0의 XML 사양 을 http://www.w3.org/TR/REC-xml/ .
XML 코멘트
클라이언트 애플리케이션과 Junos XML 프로토콜 서버는 생성한 태그 스트림의 태그 요소 간에 어느 시점에서나 XML 코멘트를 삽입할 수 있지만 태그 요소 내에는 삽입할 수 없습니다. 클라이언트 애플리케이션은 Junos XML 프로토콜 서버의 출력에서 코멘트를 처리해야 하지만 콘텐츠에 의존해서는 안 됩니다. 또한 클라이언트 애플리케이션은 코멘트를 사용하여 Junos XML 프로토콜 서버에 정보를 전달할 수 없습니다. 서버가 수신하는 코멘트를 자동으로 삭제하기 때문입니다.
XML 코멘트는 문자열 및 , 내에 묶이며 -->문자열 <!-- - - (2개의 하이픈)을 포함할 수 없습니다. 코멘트에 대한 자세한 내용은 http://www.w3.org/TR/REC-xml/ XML 사양 을(를) 참조하십시오.
다음은 XML 코멘트의 예입니다.
<!-- This is a comment. Please ignore it. -->
XML 처리 지침
XML 처리 명령(PI)은 특정 프로토콜과 관련된 정보를 포함하고 다음과 같은 형태를 니다.
<?PI-name attributes?>
Junos XML 프로토콜 세션 중에 방출되는 일부 PIS에는 클라이언트 애플리케이션이 올바른 작업을 위해 필요한 정보가 포함됩니다. 눈에 띄는 예는 클라이언트 애플리케이션과 Junos XML 프로토콜 서버가 <?xml?> 모든 Junos XML 프로토콜 세션의 시작 부분에서 각각 방출하여 어떤 버전의 XML 및 어떤 문자 인코딩 체계를 사용하는지 지정하는 요소입니다. 자세한 내용은 Junos XML 프로토콜 세션시작을 참조하십시오.
Junos XML 프로토콜 서버는 클라이언트 애플리케이션이 해석할 필요가 없는 PIS를 방출할 수도 있습니다(예: CLI를 위한 PIS). 클라이언트 애플리케이션이 PI를 이해하지 못하는 경우, PI는 오류 메시지를 나가거나 생성하는 대신 코멘트처럼 취급해야 합니다.
사전 정의된 엔터티 참조
XML 규칙에 따라 특정 문자가 정규 형식으로 표시될 수 없는 두 가지 컨텍스트가 있습니다.
개방 태그와 닫기 태그 사이에 나타나는 문자열(태그 요소의 내용)
오프닝 태그 속성에 할당된 문자열 값에서
허용되지 않은 문자를 두 컨텍스트에 포함할 때 클라이언트 애플리케이션은 허용되지 않은 문자를 나타내는 문자 문자열인 동등한 사전 정의된 엔터티 참조를 대체해야 합니다. Junos XML 프로토콜 서버는 응답 태그 요소에서 동일한 사전 정의된 엔터티 참조를 사용하기 때문에 클라이언트 애플리케이션은 응답 태그 요소를 처리할 때 이를 실제 문자로 변환할 수 있어야 합니다.
표 1 에는 허용되지 않은 문자와 태그 요소의 개폐 태그 사이에 나타나는 문자열에 대한 사전 정의된 엔터티 참조 간의 매핑이 요약되어 있습니다.
허용되지 않는 문자 |
사전 정의된 엔터티 참조 |
|---|---|
|
|
|
|
|
|
표 2 에는 허용되지 않는 문자와 속성 값에 대한 사전 정의된 엔터티 참조 간의 매핑이 요약되어 있습니다.
허용되지 않는 문자 |
사전 정의된 엔터티 참조 |
|---|---|
|
|
|
|
|
|
|
|
|
|
예를 들어, 다음 문자열이 요소에 의해 포함된 값이라고 가정해봅시다.<condition>
if (a<b && b>c) return "Peer’s not responding"
요소는 <condition> 이처럼 보입니다(가독성 만을 위해 두 줄에 나타납니다):.
<condition>if (a<b && b>c) return "Peer’s not \
responding"</condition>
마찬가지로 요소 heading 속성에 대한 값이 <example> 인 Peer’s "age" <> 40경우, 오프닝 태그는 다음과 같습니다.
<example heading="Peer's "age" <> 40">