By XML convention, there are two contexts in which certain characters cannot appear in their regular form:
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 NETCONF 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 7 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 7: Predefined Entity Reference Substitutions for Tag Content Values
|
Disallowed Character |
Predefined Entity Reference |
|---|---|
|
& (ampersand) |
& |
|
> (greater-than sign) |
> |
|
< (less-than sign) |
< |
Table 8 summarizes the mapping between disallowed characters and predefined entity references for attribute values.
Table 8: Predefined Entity Reference Substitutions for Attribute Values
|
Disallowed Character |
Predefined Entity Reference |
|---|---|
|
& (ampersand) |
& |
|
' (apostrophe) |
' |
|
> (greater-than sign) |
> |
|
< (less-than sign) |
< |
|
" (quotation mark) |
" |
As an example, suppose that the following string is the value contained by the <condition> tag element:
- if (a<b && b>c) return "Peer’s not responding"
The <condition> tag element looks like this (it appears on two lines for legibility only):
<condition>if (a<b && b>c) return "Peer’s not \
responding"</condition>
Similarly, if the value for the <example> tag element’s heading attribute is Peer’s "age" <> 40, the opening tag looks like this:
- <example heading="Peer's "age"
<> 40">