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


Documentation Conventions for Expressing XML and JSON encoded YANG Data
                             Node Instance
              draft-wu-netmod-yang-xml-doc-conventions-02

Abstract

   Many documents that define YANG modules also include YANG data node
   Instance examples presented in XML/JSON.

   IETF documentation has specific limits on line length and some YANG
   data node Instance 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 December 1, 2018.



Wu, et al.              Expires December 1, 2018                [Page 1]


Internet-Draft       YANG Documentation Conventions             May 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
     2.1.  Glossary of New Terms . . . . . . . . . . . . . . . . . .   4
   3.  Objectives  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Separating Components of a Leaf Example . . . . . . . . . . .   5
   5.  Splitting an Example Leaf Node Value Across Lines . . . . . .   6
   6.  Representing XML and JSON Encodings of Metadata Annotations .   7
   7.  Mandatory Boilerplate for Splitting Leaf node value and
       Metadata Annotations  . . . . . . . . . . . . . . . . . . . .   8
   8.  Automatic decoding From YANG data node Instance Examples with
       split line  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Backslash appears in the node value not used for
                split line . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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





Wu, et al.              Expires December 1, 2018                [Page 2]


Internet-Draft       YANG Documentation Conventions             May 2018


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

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o  data node

   o  leaf

   o  leaf-list

   o  instance

   The following term is defined in [RFC7951] and [RFC7952] and are not
   redefined here:

   o  data node Instance




Wu, et al.              Expires December 1, 2018                [Page 3]


Internet-Draft       YANG Documentation Conventions             May 2018


   o  data node identifier

2.1.  Glossary of New Terms

   Encoding function:  Convert XML/JSON encoded YANG data node instance
      Example with long lines not fitting into an Internet-Draft or RFC
      into XML/JSON encoded YANG data node instance Example with split
      line fitting into an Internet-Draft or RFC.

   Decoding function:  Re-Convert XML/JSON encoded YANG data node
      instance Example with split line fitting into an Internet-Draft or
      RFC back to valid YANG representation in data file or on the wire
      without split line.

3.  Objectives

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

   o  If the problem comes from the poorly chosen length of YANG data
      node instance encoded by XML or JSON,it is recommended to reduce
      the length of YANG data node instance name or YANG data node
      instance value to the minimum before applying document convention
      defined in this document.

   o  If the problem comes from the poorly chosen length of the YANG
      data node instance containing metadata annotation as attribute, it
      is recommended to reduce the length of each attribute to the
      minimum before applying the document convention defined in this
      document.

   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:

   o  Split long line YANG data node instance(e.g.,leaf node instance)
      exceeding 73 characters limits with the backslash ("\") and use
      backslash ("\")to indicate wrapping at the end of the line.

   o  Split long line YANG data node instance containing metadata
      annotation attributes with the backslash ("\")and use backslash
      ("\")to indicate wrapping at the end of the line.

   o  When a backslash appears in the node value not used for split
      line, the example MUST be arranged so that this backslash is not
      the final character of a broken line.





Wu, et al.              Expires December 1, 2018                [Page 4]


Internet-Draft       YANG Documentation Conventions             May 2018


   o  Allow the representation of such examples, if possible,in a way
      that is easily parsed by a human reader instead of machine or
      software component:

      *  The first child node within each parent node of the XML/JSON
         encoded YANG data node instance should be indented with a
         whitespace offset of two characters.

      *  Where possible, all line breaks should be inserted between
         metadata attributes.

      *  Where possible, all line breaks should not be inserted between
         close (">") and open ("<") angle brackets within XML encoded
         YANG data instance.

      *  Where possible, all line breaks should be inserted between
         double-quote strings or between data node identifier and data
         node separated by colon character within JSON encoded YANG data
         instance.

   o  Allow automatic generation of YANG representation without split
      line in data files or in the wire from representation of XML/JSON
      encoded Example with split line within an Internet-Draft or RFC
      presented based on document convention defined in this
      document.(See section 8)

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.




Wu, et al.              Expires December 1, 2018                [Page 5]


Internet-Draft       YANG Documentation Conventions             May 2018


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

   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.  The backslash at the
      end of the line indicates wrapping.

   o  Any continuation lines MUST align with the first line and not be
      indented with any whitespace offset.

   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.









Wu, et al.              Expires December 1, 2018                [Page 6]


Internet-Draft       YANG Documentation Conventions             May 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 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.









Wu, et al.              Expires December 1, 2018                [Page 7]


Internet-Draft       YANG Documentation Conventions             May 2018


      <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 4), (Section 5)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.

      The examples in this document adopt the conventions shown in BCP
      XX [RFCYYYY] for splitting node labels and node values or 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/JSON representation of YANG metadata annotations as
      described in [RFC7952].

   RFC Editor Note: Please replace XX and YYYY with the numbers assigned
   for this document.

8.  Automatic decoding From YANG data node Instance Examples with split
    line

   It should be noted that it is never the intention that example YANG
   data node Instance fragment generated by encoding function should be
   converted to YANG representation in data file that is passed to a
   YANG consumer.  Nevertheless, there are good reasons to be able to
   convert an YANG data node instance example with split line into valid
   YANG representation without split line in data file using decoding
   function 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.



Wu, et al.              Expires December 1, 2018                [Page 8]


Internet-Draft       YANG Documentation Conventions             May 2018


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




Wu, et al.              Expires December 1, 2018                [Page 9]


Internet-Draft       YANG Documentation Conventions             May 2018


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

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/info/rfc7951>.

   [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/>.

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



Wu, et al.              Expires December 1, 2018               [Page 10]


Internet-Draft       YANG Documentation Conventions             May 2018


        <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


   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 December 1, 2018               [Page 11]