idnits 2.17.1
draft-wu-netmod-yang-xml-doc-conventions-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 26, 2018) is 2280 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFCYYYY' is mentioned on line 263, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Netmod Working Group Q. Wu
3 Internet-Draft Huawei
4 Intended status: Best Current Practice A. Farrel
5 Expires: July 30, 2018 Juniper Networks
6 B. Claise
7 Cisco Systems, Inc.
8 January 26, 2018
10 Documentation Conventions for Expressing YANG in XML
11 draft-wu-netmod-yang-xml-doc-conventions-00
13 Abstract
15 Many documents that define YANG modules also include examples
16 presented in XML.
18 IETF documentation has specific limits on line length and some XML
19 examples have to include line wraps that would not normally be
20 allowed according to the XML representation rules of RFC7950 and
21 RFC7952.
23 This document lays out documentation conventions that allow YANG
24 examples to be presented in IETF documentation when leaf node
25 encoding would otherwise exceed the maximum line length. There are
26 no implications in this document for YANG parsers: this document does
27 not change the rules for presenting YANG models or for encoding YANG
28 in data files or in the wire.
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at https://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on July 30, 2018.
47 Copyright Notice
49 Copyright (c) 2018 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (https://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
65 2. Conventions Used in this Document . . . . . . . . . . . . . . 3
66 3. Separating Components of a Leaf Example . . . . . . . . . . . 3
67 4. Splitting an Example Leaf Node Value Across Lines . . . . . . 4
68 5. Mandatory Boilerplate Text . . . . . . . . . . . . . . . . . 5
69 6. Representing XML Encodings of Metadata Annotations . . . . . 6
70 7. Mandatory Boilerplate for Splitting Metadata Annotations . . 6
71 8. Automatic Generation of Valid XML From Examples . . . . . . . 7
72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
75 12. Normative References . . . . . . . . . . . . . . . . . . . . 8
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
78 1. Introduction
80 YANG [RFC7950] defines four main types of data node for data modeling
81 and describes how these are represented in XML [XML]. For list nodes
82 and container nodes, any whitespace, carriage returns, or line feeds
83 between the subelements is insignificant, i.e., an implementation MAY
84 insert whitespace, carriage return, or line feed characters between
85 subelements.
87 However for leaf nodes, [RFC7950] section 7.6.6 says
89 The value of the leaf node is encoded to XML according to the type
90 and is sent as character data in the element.
92 Thus whitespace, carriage return, and line feed characters are
93 interpreted as part of the leaf value if the leaf is of type string
94 and must not be included. The same applies to leaf-list nodes.
96 However, when documenting examples of YANG modules represented in XML
97 encoding it is possible that the encoding of a single leaf node will
98 exceed the available line length (73 characters).
100 This document describes documentation conventions that allow the
101 presentation of such examples in a way that is easily parsed by a
102 human reader, but which is not representative of how the XML must be
103 presented to a software component or carried on the wire.
105 There are no implications in this document for YANG parsers: this
106 document does not change the rules for presenting YANG models or for
107 encoding YANG in data files or in the wire.
109 2. Conventions Used in this Document
111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
113 "OPTIONAL" in this document are to be interpreted as described in BCP
114 14 [RFC2119] [RFC8174] when, and only when, they appear in all
115 capitals, as shown here.
117 3. Separating Components of a Leaf Example
119 An example of the documentation of a leaf node is shown in Figure 1.
120 The leaf is called "long-leaf-node-name" and is assigned the value
121 "long-leaf-node-value". As can be seen in the example, this fits on
122 one line. However it would only take the addition of a few more
123 characters to the node label or value for the example to overflow the
124 73 character limit.
126 long-leaf-node-value
128 Figure 1: A Simple Leaf Node Example
130 For the sake of documentation, the representation shown in Figure 2
131 SHALL be considered as equivalent to that shown in Figure 1, but when
132 a document uses this convention it MUST also include the text shown
133 in Section 5.
135
136 long-leaf-node-value
137
139 Figure 2: A Split Leaf Node Example
141 4. Splitting an Example Leaf Node Value Across Lines
143 When the XML representation of a leaf node value in an example would
144 result in a line being longer than the maximum line length for an
145 IETF document the value of the leaf node must be split and printed on
146 more than one lines. This is most likely to happen when the example
147 leaf node contains a string. Indeed, if this problem arises for
148 other leaf types it may be indicative of poorly chosen leaf values,
149 and the YANG definitions should be revised.
151 In this case, conventions MUST be observed:
153 o The broken line MUST be terminated with a backslash ("\") without
154 the addition of any additional space before the backslash and with
155 no further characters after the backslash.
157 o Any continuation lines MUST be indented with a whitespace offset
158 of at least two characters.
160 o When a backslash appears in the node value, the example MUST be
161 arranged so that the backslash is not the final character of a
162 broken line
164 Furthermore, whenever a document uses this convention it MUST also
165 include the text shown in Section 5.
167 Figure 3 shows an example leaf with a long value. As can be seen,
168 the addition of a few more characters would cause the line to be too
169 long.
171 Figure 4 shows a semantically equivalent representation of the
172 example if the text from Section 5 is also present.
174
175 Once upon a time, in a land far away, there lived a Great King.
176
178 Figure 3: An Example Leaf Node With a Long String Value
180
181 Once upon a time, \
182 in a land far away, \
183 there lived a Great King.
184
186 Figure 4: A Long String Leaf Node Example Split Across Lines
188 Figure 5 and Figure 6 show a more complex example where the node
189 value includes both line feeds and a backslash. Note how the line
190 breaks are arranged to avoid potential confusion and to make the real
191 characters evident.
193
194 Punctuation is important. As are line feeds.
195 Some characters are special. E.g., the backslash \. Don't forget.
196
198 Figure 5: An Example Leaf Node With a Complex String Value
200
201 Punctuation is important. \
202 As are line feeds.
203 Some characters are special. \
204 E.g., the backslash \. \
205 Don't forget.
206
208 Figure 6: An Example Leaf Node With a Complex String Value Split
209 Across Lines
211 5. Mandatory Boilerplate Text
213 When either of the conventions described in Section 3 or Section 4 is
214 used for the benefit of the representation of an example of a YANG
215 module or YANG fragment in XML, the following text MUST be included
216 in the document presenting the example.
218 The examples in this document adopt the conventions shown in BCP
219 XX [RFCYYYY] for splitting node labels and node values onto
220 separate lines. This convention is used to make the examples
221 easier to read but does not change the encoding rules for the XML
222 representation of YANG as described in [RFC7950].
224 RFC Editor Note: Please replace XX and YYYY with the numbers assigned
225 for this document.
227 6. Representing XML Encodings of Metadata Annotations
229 [RFC7952] section 5.1 provides an encoding rule for metadata
230 annotations in XML.
232 When an example XML representation of a leaf node element that
233 includes metadata attributes results in a line being longer than the
234 maximum number of characters allowed in a line of an IETF document,
235 the value of the leaf node must be split across more than one line.
237 Where possible, all line breaks should be inserted between metadata
238 attributes. Continuation lines MUST start with a whitespace offset
239 of at least two characters. The leading and trailing whitespace of
240 each line MUST be ignored. Figure 7 gives an example.
242 Whenever this documentation convention is used, the boilerplate text
243 shown in Section 7 MUST be present in the document using the
244 convention.
246
249 /t:top/t:interface[t:name="Ethernet0/0"]/t:mtu/t:anotherattribute
250 /t:afinalattribute
251
253 Figure 7: An Example Leaf Node With Metadata Split Across Lines
255 7. Mandatory Boilerplate for Splitting Metadata Annotations
257 When the convention described in Section 6 is used for the benefit of
258 the representation of an example of a YANG module or YANG fragment
259 containing metadata annotations in XML, the following text MUST be
260 included in the document presenting the example.
262 The examples in this document adopt the conventions shown in BCP
263 XX [RFCYYYY] for splitting metadata annotation across multiple
264 lines. This convention is used to make the examples easier to
265 read but does not change the encoding rules for the XML
266 representation of YANG metadata annotations as described in
267 [RFC7952].
269 RFC Editor Note: Please replace XX and YYYY with the numbers assigned
270 for this document.
272 8. Automatic Generation of Valid XML From Examples
274 It should be noted that it is never the intention that example YANG
275 fragment should be converted to XML that is passed to a YANG
276 consumer. Nevertheless, there are good reasons to be able to convert
277 an example into valid YANG in order to parse it and check its
278 validity against the YANG model itself. This will ensure that
279 examples in documents are accurate and useful.
281 When parsing a leaf or leaf-list node in an example, the following
282 rules should be applied to generate valid XML.
284 o If a white space, carriage return, or line feed character is
285 encountered between close (">") and open ("<") angle brackets it
286 should be stripped.
288 o If a white space, carriage return, or line feed character is
289 encountered within a string value of a leaf node or leaf-list
290 node, it should generally be preserved exactly as shown except in
291 the special case that follows.
293 o If a backslash character ("\") appears within the string value of
294 a leaf node or leaf-list node and if and only if it is immediately
295 followed by a carriage return or line feed character then all
296 carriage return, line feed, and whitespace characters should be
297 stripped until the next character is encountered.
299 o If a white space, carriage return, or line feed character is
300 encountered within metadata annotations, but not within quotes, it
301 should be stripped. Parsing may expect the next valid character
302 found to indicate the start of a new metadata attribute.
304 o If a backslash character ("\") appears within the quoted value of
305 a metadata attribute and if and only if it is immediately followed
306 by a carriage return or line feed character then all carriage
307 return, line feed, and whitespace characters should be stripped
308 until the next character is encountered.
310 9. Security Considerations
312 There is no direct security impact related to the XML encoding
313 documentation convention described in this document. However,
314 attempting to provide actual XML using the documentation conventions
315 described in this document would have unpredictable results. The
316 risk here is that someone uses an example as a template for actual
317 XML. The mandatory boilerplate text provides a mitigation against
318 this risk.
320 10. IANA Considerations
322 There are no IANA requests or assignments included in this document.
324 11. Acknowledgements
326 Thanks to Kent Watsen for discussions that kept us close to being on
327 the right track. Additional thanks to John Scudder for flagging some
328 nits.
330 12. Normative References
332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
333 Requirement Levels", BCP 14, RFC 2119,
334 DOI 10.17487/RFC2119, March 1997,
335 .
337 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
338 RFC 7950, DOI 10.17487/RFC7950, August 2016,
339 .
341 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
342 RFC 7952, DOI 10.17487/RFC7952, August 2016,
343 .
345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
347 May 2017, .
349 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
350 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
351 Edition)", World Wide Web Consortium Recommendation REC-
352 xml-20081126, November 2008,
353 .
355 Authors' Addresses
357 Qin Wu
358 Huawei
359 101 Software Avenue, Yuhua District
360 Nanjing, Jiangsu 210012
361 China
363 Email: bill.wu@huawei.com
364 Adrian Farrel
365 Juniper Networks
367 Email: afarrel@juniper.net
369 Benoit Claise
370 Cisco Systems, Inc.
371 De Kleetlaan 6a b1
372 1831 Diegem
373 Belgium
375 Phone: +32 2 704 5622
376 Email: bclaise@cisco.com