Netmod Working Group Q. Wu
Internet-Draft Huawei
Intended status: Best Current Practice A. Farrel
Expires: July 30, 2018 Juniper Networks
B. Claise
Cisco Systems, Inc.
January 26, 2018
Documentation Conventions for Expressing YANG in XML
draft-wu-netmod-yang-xml-doc-conventions-00
Abstract
Many documents that define YANG modules also include examples
presented in XML.
IETF documentation has specific limits on line length and some XML
examples have to include line wraps that would not normally be
allowed according to the XML representation rules of RFC7950 and
RFC7952.
This document lays out documentation conventions that allow YANG
examples to be presented in IETF documentation when leaf node
encoding would otherwise exceed the maximum line length. There are
no implications in this document for YANG parsers: this document does
not change the rules for presenting YANG models or for encoding YANG
in data files or in the wire.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2018.
Wu, et al. Expires July 30, 2018 [Page 1]
Internet-Draft YANG Documentation Conventions January 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 3
3. Separating Components of a Leaf Example . . . . . . . . . . . 3
4. Splitting an Example Leaf Node Value Across Lines . . . . . . 4
5. Mandatory Boilerplate Text . . . . . . . . . . . . . . . . . 5
6. Representing XML Encodings of Metadata Annotations . . . . . 6
7. Mandatory Boilerplate for Splitting Metadata Annotations . . 6
8. Automatic Generation of Valid XML From Examples . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
12. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
YANG [RFC7950] defines four main types of data node for data modeling
and describes how these are represented in XML [XML]. For list nodes
and container nodes, any whitespace, carriage returns, or line feeds
between the subelements is insignificant, i.e., an implementation MAY
insert whitespace, carriage return, or line feed characters between
subelements.
However for leaf nodes, [RFC7950] section 7.6.6 says
The value of the leaf node is encoded to XML according to the type
and is sent as character data in the element.
Thus whitespace, carriage return, and line feed characters are
interpreted as part of the leaf value if the leaf is of type string
and must not be included. The same applies to leaf-list nodes.
Wu, et al. Expires July 30, 2018 [Page 2]
Internet-Draft YANG Documentation Conventions January 2018
However, when documenting examples of YANG modules represented in XML
encoding it is possible that the encoding of a single leaf node will
exceed the available line length (73 characters).
This document describes documentation conventions that allow the
presentation of such examples in a way that is easily parsed by a
human reader, but which is not representative of how the XML must be
presented to a software component or carried on the wire.
There are no implications in this document for YANG parsers: this
document does not change the rules for presenting YANG models or for
encoding YANG in data files or in the wire.
2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Separating Components of a Leaf Example
An example of the documentation of a leaf node is shown in Figure 1.
The leaf is called "long-leaf-node-name" and is assigned the value
"long-leaf-node-value". As can be seen in the example, this fits on
one line. However it would only take the addition of a few more
characters to the node label or value for the example to overflow the
73 character limit.
<long-leaf-node-label>long-leaf-node-value</long-leaf-node-label>
Figure 1: A Simple Leaf Node Example
For the sake of documentation, the representation shown in Figure 2
SHALL be considered as equivalent to that shown in Figure 1, but when
a document uses this convention it MUST also include the text shown
in Section 5.
<long-leaf-node-label>
long-leaf-node-value
</long-leaf-node-label>
Figure 2: A Split Leaf Node Example
Wu, et al. Expires July 30, 2018 [Page 3]
Internet-Draft YANG Documentation Conventions January 2018
4. Splitting an Example Leaf Node Value Across Lines
When the XML representation of a leaf node value in an example would
result in a line being longer than the maximum line length for an
IETF document the value of the leaf node must be split and printed on
more than one lines. This is most likely to happen when the example
leaf node contains a string. Indeed, if this problem arises for
other leaf types it may be indicative of poorly chosen leaf values,
and the YANG definitions should be revised.
In this case, conventions MUST be observed:
o The broken line MUST be terminated with a backslash ("\") without
the addition of any additional space before the backslash and with
no further characters after the backslash.
o Any continuation lines MUST be indented with a whitespace offset
of at least two characters.
o When a backslash appears in the node value, the example MUST be
arranged so that the backslash is not the final character of a
broken line
Furthermore, whenever a document uses this convention it MUST also
include the text shown in Section 5.
Figure 3 shows an example leaf with a long value. As can be seen,
the addition of a few more characters would cause the line to be too
long.
Figure 4 shows a semantically equivalent representation of the
example if the text from Section 5 is also present.
<long-leaf-string-node-label>
Once upon a time, in a land far away, there lived a Great King.
</long-leaf-string-node-label>
Figure 3: An Example Leaf Node With a Long String Value
Wu, et al. Expires July 30, 2018 [Page 4]
Internet-Draft YANG Documentation Conventions January 2018
<long-leaf-string-node-label>
Once upon a time, \
in a land far away, \
there lived a Great King.
</long-leaf-string-node-label>
Figure 4: A Long String Leaf Node Example Split Across Lines
Figure 5 and Figure 6 show a more complex example where the node
value includes both line feeds and a backslash. Note how the line
breaks are arranged to avoid potential confusion and to make the real
characters evident.
<long-leaf-complex-string-node-label>
Punctuation is important. As are line feeds.
Some characters are special. E.g., the backslash \. Don't forget.
</long-leaf-string-node-label>
Figure 5: An Example Leaf Node With a Complex String Value
<long-leaf-complex-string-node-label>
Punctuation is important. \
As are line feeds.
Some characters are special. \
E.g., the backslash \. \
Don't forget.
</long-leaf-string-node-label>
Figure 6: An Example Leaf Node With a Complex String Value Split
Across Lines
5. Mandatory Boilerplate Text
When either of the conventions described in Section 3 or Section 4 is
used for the benefit of the representation of an example of a YANG
module or YANG fragment in XML, the following text MUST be included
in the document presenting the example.
The examples in this document adopt the conventions shown in BCP
XX [RFCYYYY] for splitting node labels and node values onto
separate lines. This convention is used to make the examples
easier to read but does not change the encoding rules for the XML
representation of YANG as described in [RFC7950].
Wu, et al. Expires July 30, 2018 [Page 5]
Internet-Draft YANG Documentation Conventions January 2018
RFC Editor Note: Please replace XX and YYYY with the numbers assigned
for this document.
6. Representing XML Encodings of Metadata Annotations
[RFC7952] section 5.1 provides an encoding rule for metadata
annotations in XML.
When an example XML representation of a leaf node element that
includes metadata attributes results in a line being longer than the
maximum number of characters allowed in a line of an IETF document,
the value of the leaf node must be split across more than one line.
Where possible, all line breaks should be inserted between metadata
attributes. Continuation lines MUST start with a whitespace offset
of at least two characters. The leading and trailing whitespace of
each line MUST be ignored. Figure 7 gives an example.
Whenever this documentation convention is used, the boilerplate text
shown in Section 7 MUST be present in the document using the
convention.
<error-path
xmlns:t="http://example.com/schema/1.2/config/verylongpathname\
thatcannotfitononeline">
/t:top/t:interface[t:name="Ethernet0/0"]/t:mtu/t:anotherattribute
/t:afinalattribute
</error-path>
Figure 7: An Example Leaf Node With Metadata Split Across Lines
7. Mandatory Boilerplate for Splitting Metadata Annotations
When the convention described in Section 6 is used for the benefit of
the representation of an example of a YANG module or YANG fragment
containing metadata annotations in XML, the following text MUST be
included in the document presenting the example.
The examples in this document adopt the conventions shown in BCP
XX [RFCYYYY] for splitting metadata annotation across multiple
lines. This convention is used to make the examples easier to
read but does not change the encoding rules for the XML
representation of YANG metadata annotations as described in
[RFC7952].
Wu, et al. Expires July 30, 2018 [Page 6]
Internet-Draft YANG Documentation Conventions January 2018
RFC Editor Note: Please replace XX and YYYY with the numbers assigned
for this document.
8. Automatic Generation of Valid XML From Examples
It should be noted that it is never the intention that example YANG
fragment should be converted to XML that is passed to a YANG
consumer. Nevertheless, there are good reasons to be able to convert
an example into valid YANG in order to parse it and check its
validity against the YANG model itself. This will ensure that
examples in documents are accurate and useful.
When parsing a leaf or leaf-list node in an example, the following
rules should be applied to generate valid XML.
o If a white space, carriage return, or line feed character is
encountered between close (">") and open ("<") angle brackets it
should be stripped.
o If a white space, carriage return, or line feed character is
encountered within a string value of a leaf node or leaf-list
node, it should generally be preserved exactly as shown except in
the special case that follows.
o If a backslash character ("\") appears within the string value of
a leaf node or leaf-list node and if and only if it is immediately
followed by a carriage return or line feed character then all
carriage return, line feed, and whitespace characters should be
stripped until the next character is encountered.
o If a white space, carriage return, or line feed character is
encountered within metadata annotations, but not within quotes, it
should be stripped. Parsing may expect the next valid character
found to indicate the start of a new metadata attribute.
o If a backslash character ("\") appears within the quoted value of
a metadata attribute and if and only if it is immediately followed
by a carriage return or line feed character then all carriage
return, line feed, and whitespace characters should be stripped
until the next character is encountered.
9. Security Considerations
There is no direct security impact related to the XML encoding
documentation convention described in this document. However,
attempting to provide actual XML using the documentation conventions
described in this document would have unpredictable results. The
risk here is that someone uses an example as a template for actual
Wu, et al. Expires July 30, 2018 [Page 7]
Internet-Draft YANG Documentation Conventions January 2018
XML. The mandatory boilerplate text provides a mitigation against
this risk.
10. IANA Considerations
There are no IANA requests or assignments included in this document.
11. Acknowledgements
Thanks to Kent Watsen for discussions that kept us close to being on
the right track. Additional thanks to John Scudder for flagging some
nits.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
RFC 7952, DOI 10.17487/RFC7952, August 2016,
<https://www.rfc-editor.org/info/rfc7952>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Wu, et al. Expires July 30, 2018 [Page 8]
Internet-Draft YANG Documentation Conventions January 2018
Adrian Farrel
Juniper Networks
Email: afarrel@juniper.net
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Wu, et al. Expires July 30, 2018 [Page 9]