XML and Junos XML Management Protocol Conventions Overview

Request and Response Tag Elements

A request tag element is one generated by a client application to request information about a device’s current status or configuration, or to change the configuration. A request tag element corresponds to a CLI operational or configuration command. It can occur only within an <rpc> tag. For information about the <rpc> element, see Sending Requests to the Junos XML Protocol Server.

A response tag element represents the Junos XML protocol server’s reply to a request tag element and occurs only within an <rpc-reply> tag. For information about the <rpc-reply> element, see Parsing the Junos XML Protocol Server Response.

The following example represents an exchange in which a client application emits the <get-interface-information> request tag with the <extensive/> flag and the Junos XML protocol server returns the <interface-information> response element.

For information about the attributes in the opening rpc-reply tag, see Parsing the Junos XML Protocol Server Response. For information about the xmlns attribute in the opening <interface-information> tag, see Requesting Operational Information Using the Junos XML Protocol.

Child Tag Elements of a Request Tag Element

Some request tag elements contain child tag elements. For configuration requests, each child tag element represents a configuration element (hierarchy level or configuration object). For operational requests, each child tag element represents one of the options you provide on the command line when issuing the equivalent CLI command.

Some requests have mandatory child tag elements. To make a request successfully, a client application must emit the mandatory tag elements within the request tag element’s opening and closing tags. If any of the children are themselves container tag elements, the opening tag for each must occur before any of the tag elements it contains, and the closing tag must occur before the opening tag for another tag element at its hierarchy level.

In most cases, the client application can emit children that occur at the same level within a container tag element in any order. The important exception is a configuration element that has an identifier tag element, which distinguishes the configuration element from other elements of its type. The identifier tag element must be the first child tag element in the container tag element. Most frequently, the identifier tag element specifies the name of the configuration element and is called <name>.

Child Tag Elements of a Response Tag Element

The child tag elements of a response tag element represent the individual data items returned by the Junos XML protocol server for a particular request. The children can be either individual tag elements (empty tags or tag element triples) or container tag elements that enclose their own child tag elements. For some container tag elements, the Junos XML protocol server returns the children in alphabetical order. For other elements, the children appear in the order in which they were created in the configuration.

The set of child tag elements that can occur in a response or within a container tag element is subject to change in later releases of the Junos XML API. Client applications must not rely on the presence or absence of a particular tag element in the Junos XML protocol server’s output, nor on the ordering of child tag elements within a response tag element. For the most robust operation, include logic in the client application that handles the absence of expected tag elements or the presence of unexpected ones as gracefully as possible.

Spaces, Newline Characters, and Other White Space

As dictated by the XML specification, the Junos XML protocol server ignores white space (spaces, tabs, newline characters, and other characters that represent white space) that occurs between tag elements in the tag stream generated by a client application. Client applications can, but do not need to, include white space between tag elements. However, they must not insert white space within an opening or closing tag. If they include white space in the contents of a tag element that they are submitting as a change to the candidate configuration, the Junos XML protocol server preserves the white space in the configuration database.

In its responses, the Junos XML protocol server includes white space between tag elements to enhance the readability of responses that are saved to a file: it uses newline characters to put each tag element on its own line, and spaces to indent child tag elements to the right compared to their parents. A client application can ignore or discard the white space, particularly if it does not store responses for later review by human users. However, it must not depend on the presence or absence of white space in any particular location when parsing the tag stream.

For more information about white space in XML documents, see the XML specification from the World Wide Web Consortium (W3C), Extensible Markup Language (XML) 1.0, at http://www.w3.org/TR/REC-xml/ .

XML Comments

Client applications and the Junos XML protocol server can insert XML comments at any point between tag elements in the tag stream they generate, but not within tag elements. Client applications must handle comments in output from the Junos XML protocol server gracefully but must not depend on their content. Client applications also cannot use comments to convey information to the Junos XML protocol server, because the server automatically discards any comments it receives.

XML comments are enclosed within the strings <!-- and -->, and cannot contain the string - - (two hyphens). For more details about comments, see the XML specification at http://www.w3.org/TR/REC-xml/ .

The following is an example of an XML comment:

XML Processing Instructions

An XML processing instruction (PI) contains information relevant to a particular protocol and has the following form:

Some PIs emitted during a Junos XML protocol session include information that a client application needs for correct operation. A prominent example is the <?xml?> element, which the client application and Junos XML protocol server each emit at the beginning of every Junos XML protocol session to specify which version of XML and which character encoding scheme they are using. For more information, see Starting Junos XML Protocol Sessions.

The Junos XML protocol server can also emit PIs that the client application does not need to interpret (for example, PIs intended for the CLI). If the client application does not understand a PI, it must treat the PI like a comment instead of exiting or generating an error message.

Predefined Entity References

By XML convention, there are two contexts in which certain characters cannot appear in their regular form:

• In the string that appears between opening and closing tags (the contents of the tag element)

• In the string value assigned to an attribute of an opening tag

When including a disallowed character in either context, client applications must substitute the equivalent predefined entity reference, which is a string of characters that represents the disallowed character. Because the Junos XML protocol server uses the same predefined entity references in its response tag elements, the client application must be able to convert them to actual characters when processing response tag elements.

Table 1 summarizes the mapping between disallowed characters and predefined entity references for strings that appear between the opening and closing tags of a tag element.

Table 2 summarizes the mapping between disallowed characters and predefined entity references for attribute values.

As an example, suppose that the following string is the value contained by the <condition> element:

The <condition> element looks like this (it appears on two lines for legibility only):

Similarly, if the value for the <example> element’s heading attribute is Peer’s "age" <> 40, the opening tag looks like this: