Netmod Working Group Q. Wu
Internet-Draft Huawei
Intended status: Best Current Practice A. Farrel
Expires: November 30, 2018 Juniper Networks
B. Claise
Cisco Systems, Inc.
May 29, 2018

Documentation Conventions for Expressing YANG in XML
draft-wu-netmod-yang-xml-doc-conventions-01

Abstract

Many documents that define YANG modules also include artwork examples presented in XML/JSON.

IETF documentation has specific limits on line length and some artwork examples such as XML examples have to include line wraps that would not normally be allowed according to the XML representation rules of RFC7950 and RFC7952.The same applies to JSON.

This document lays out documentation conventions that allow YANG examples to be presented in IETF documentation when XML/JSON encoded YANG data instance would otherwise exceed the maximum line length and provide consistent XML/JSON encoded YANG data node instance example within an Internet-Draft or RFC. 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 November 30, 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

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

Thus whitespace, carriage return, and line feed characters interpreted as part of the leaf value when the leaf is of type string must not be included. The same applies to leaf-list nodes.

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 YANG examples to be presented in IETF documentation when XML/JSON encoded YANG data instance would otherwise exceed the maximum line length and provide consistent XML/JSON encoded YANG data node instance example within an Internet-Draft or RFC. These document conventions also 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. Objectives

To reduce complexity of XML/JSON encoded YANG data node instance, the following assumptions are made:

In order to provide consistent XML/JSON encoded YANG data node instance example within an Internet-Draft or RFC, the following design criteria are used:

4. 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 purpose, 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 7. Note that the first example representation in figure 2 is more easily parsed by a human reader than the second example in figure 2.

      
<long-leaf-node-label> \
long-leaf-node-value \
</long-leaf-node-label>
or
<long-leaf-node-label> long-le \
af-node-value </long-leaf-nod \
e-label>  
        

Figure 2: A Split Leaf Node Example

5. 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:

These conventions also apply to JSON representation of a leaf node value [RFC7951].

Furthermore, whenever a document uses this convention it MUST also include the text shown in Section 7.

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 7 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

      
     <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

6. Representing XML and JSON Encodings of Metadata Annotations

[RFC7952] section 5.1 and section 5.2 provide an encoding rule for metadata annotations in XML and JSON respectively.

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 align with the first line and not be indented with any whitespace. The leading and trailing whitespace of each line MUST be ignored. Figure 5 gives a XML example.

When an example JSON representation of a leaf node element that includes metadata attributes starting with the "@" character 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. Continuation lines MUST align with the first line and indented with one whitespace character. The leading and trailing whitespace of each line MUST be ignored. Figure 6 gives a JSON example.

Whenever this documentation convention is used, the boilerplate text shown in Section 7 MUST be present in the document using the convention.

    
   <foo xmlns:elm=http://example.org/example-last-modified\
   elm:last-modified="2015-09-16T10:27:35+02:00">
     ...
   </foo>     
        

Figure 5: An XML Example Leaf Node With Metadata Split Across Lines

   "cask": {
     "@": {
       "example-org-example-last-modified:last-modified":\
       "2015-09-16T10:27:35+02:00"
     },
     ...
   }

Figure 6: A JSON Example Leaf Node With Metadata Split Across Lines

7. Mandatory Boilerplate for Splitting Leaf node value and Metadata Annotations

When the conventions described in ,,Section 6 are used for the benefit of the representation of an example of a YANG module or YANG fragment in XML/JSON or YANG frament containing metadata annotations in XML/JSON, the following text MUST be included in the document presenting the example.

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.

9. Security Considerations

There is no direct security impact related to the XML/JSON encoding documentation convention described in this document. However, attempting to provide actual XML/JSON 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 XML/JSON. 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. Also thanks Martin Bjorklund, Charles Eckel, Robert Wilton and many others for valuable comments and review.

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.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[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.

Appendix A. Backslash appears in the node value not used for split line

Figure 7 and Figure 8 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., //Same line as the first row
  the backslash \. Don't forget.    //Same line as the firs row
</long-leaf-string-node-label>
          
        

Figure 7: 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 8: An Example Leaf Node With a Complex String Value Split Across Lines

Authors' Addresses

Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China EMail: bill.wu@huawei.com
Adrian Farrel Juniper Networks EMail: afarrel@juniper.net
Benoît Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem, Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com