idnits 2.17.1 draft-wu-netmod-yang-xml-doc-conventions-05.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2018) is 2141 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) == Unused Reference: 'RFC8340' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 456, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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: December 18, 2018 Juniper Networks 6 B. Claise 7 Cisco Systems, Inc. 8 June 16, 2018 10 Documentation Conventions for lines wrapping and indentation in authored 11 work 12 draft-wu-netmod-yang-xml-doc-conventions-05 14 Abstract 16 Many documents that define YANG modules or YANG fragments also 17 include protocol message instance data examples. 19 IETF documentation has specific limits on line length (73 characters) 20 and some YANG fragment example or protocol message instance data 21 examples such as XML encoded YANG data node instance examples have to 22 include line wraps that would not normally be allowed according to 23 the XML representation rules of RFC7950 and RFC7952. 25 This document lays out documentation conventions that allow authored 26 work to be presented in IETF documentation when authored work such as 27 YANG fragment or protocol message instance data example would 28 otherwise exceed the maximum line length and provide consistent 29 representation of authored work within an Internet-Draft or RFC. 30 There are no implications in this document for YANG tools: this 31 document does not change the rules for presenting authored work in 32 data files or in the wire. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 18, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 69 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 70 3. Long line wrapping Example . . . . . . . . . . . . . . . . . 4 71 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Line wrapping and indentation document convention . . . . . . 5 73 5.1. Long line wrapping . . . . . . . . . . . . . . . . . . . 6 74 5.2. Line unwrapping . . . . . . . . . . . . . . . . . . . . . 7 75 5.3. Auto indentation and dedentation . . . . . . . . . . . . 8 76 6. Limitation and complexity . . . . . . . . . . . . . . . . . . 8 77 6.1. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Representing XML and JSON Encodings of Metadata 84 Annotations . . . . . . . . . . . . . . . . . . . . 10 85 Appendix B. Auto-wrapping tool code . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 When documenting authored work such as YANG fragments example of 91 example of YANG module represented in XML encoding it is possible 92 that the representation of these authored work will exceed the 93 available line length. Indentation may further aggravate this issue. 94 The line wrapping is needed for formatting purposes, however 95 different document author may take different ways to wrap line which 96 makes difficult to improve the readability and interoperability of 97 published YANG data models. 99 This document lays out documentation conventions that allow authored 100 work to be presented in IETF documentation when authored work such as 101 YANG fragment or protocol message instance data example would 102 otherwise exceed the maximum line length and provide consistent 103 representation of authored work within an Internet-Draft or RFC. 105 Document conventions defined in this document are not representative 106 of how the Authored work must be presented to a software component or 107 carried on the wire. There are no implications in this document for 108 YANG tools(e.g., libyang parser): this document does not change the 109 rules for presenting YANG models or for encoding YANG in data files 110 or in the wire. 112 2. Conventions Used in this Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 The following terms are defined in [RFC7950] and are not redefined 121 here: 123 o data node 125 o leaf 127 o leaf-list 129 o instance 131 The following term is defined in [RFC7951] and [RFC7952] and are not 132 redefined here: 134 o data node Instance 136 o data node identifier 138 The following terms are defined in [RFC8340]and 139 [I-D.ietf-netmod-rfc6087bis]. 141 2.1. Glossary of New Terms 143 Authored work: A set of text format work representing YANG 144 fragments, and protocol message instance data except YANG Tree 145 Diagrams. 147 Wrap: Convert authored work with long lines not fitting into an 148 Internet-Draft or RFC into authored work with split line fitting 149 into an Internet-Draft or RFC. 151 Unwrap: Re-Convert authored work with split line fitting into an 152 Internet-Draft or RFC back to valid authored work without split 153 line that can be consumed by a software component or carried on 154 the wire. 156 Indent: used to describe the distance, or number of blank spaces 157 used to separate a paragraph from the left or right margins. 159 Libyang parser: YANG tool and library for parsing and validating 160 YANG schemas and instance data. 162 3. Long line wrapping Example 164 An example of the documentation of a leaf node is shown in Figure 1. 165 The container node is called , any whitespace, 166 carriage returns, or line feeds between the subelements is insignificant, i.e., an implementation MAY insert 168 whitespace, carriage return, or line feed characters between 169 subelements. The leaf is called "long-leaf-node-label" and is 170 assigned the value "long-leaf-node-value". As can be seen in the 171 example, this fits on one line. However it would only take the 172 addition of a few more characters to the node label or value for the 173 example to overflow the 73 character limit if the line of leaf node 174 instance is indented (e.g., start below with a 175 whitespace offset of two characters. . 177 178 long-leaf-node-value 179 181 Figure 1: A Simple Leaf Node Example 183 For the sake of documentation purpose, the representation shown in 184 Figure 2 SHALL be considered as equivalent to that shown in Figure 1, 185 but when a document uses this convention it MUST also include the 186 text shown in Figure 3. Note that the first example representation 187 in figure 2 is more easily parsed by a human reader than the second 188 example in figure 2. 190 191 \ 192 long-leaf-node-value\ 193 194 195 Or 196 197 long-leaf-node-value 199 201 Figure 2: A Split Leaf Node Example 203 4. Objectives 205 In order to allow authored work to be presented in IETF documentation 206 when authored work such as YANG fragment or protocol message instance 207 data example would otherwise exceed the maximum line length and 208 provide consistent representation of the authored work within an 209 Internet-Draft or RFC, the following design criteria are used: 211 o Allow automatic wrapping line when any line presented in the 212 authored work of I-D or RFCs exceed the maximum line length. 214 o Allow automatic unwrapping line in the artwork when the artwork 215 needs to be presented to a software component or carried on the 216 wire. 218 5. Line wrapping and indentation document convention 220 When the representation of an authored work (e.g.,a leaf node 221 instance representation) in an example would result in a line being 222 longer than the maximum line length for an IETF document the long 223 line must be split and presented on more than one lines. The new 224 line may be indented, if necessary, so that it starts below the first 225 line with a whitespace offset of two characters, which improve 226 readability and interoperability of published YANG data models. 228 When these authored work with split lines needs to be fed into 229 software component or carried in the wire, these authored work with 230 split lines should be unwrapped and reversed into the valid authored 231 work with long line. If the indentation is applied to authored work 232 with split lines, the indentation should be removed during unwrapped 233 process. 235 5.1. Long line wrapping 237 Long line wrapping most likely to happen when the authored work 238 example such as leaf node contains built-in type string or datetime 239 or container node and list node includes metadata attributes. 240 Indeed, if this problem arises for other YANG types it may be 241 indicative of poorly chosen YANG type values, and the YANG 242 definitions should be revised before applying document convention for 243 line wrapping defined in this document. 245 In the case of long line exceeding 73 characters, the following long 246 line wrapping conventions MUST be observed: 248 o Split long line in the authored work (e.g.,leaf node instance, 249 YANG data node instance containing metadata annotation attributes) 250 exceeding 73 characters limits with the backslash ("\") and use 251 backslash ("\")to indicate wrapping at the end of the line. The 252 broken line MUST be terminated with a backslash ("\") without the 253 addition of any additional space before the backslash and with no 254 further characters after the backslash. 256 o Any continuation lines or new line MUST align with the first line 257 and MAY chose be indented with two whitespace offset for 258 readability purposes. 260 o When a backslash appears in any line not used for split line, the 261 representation of this artwork MUST be arranged so that this 262 backslash is not the final character of a broken line. If this 263 backslash is the second last character (e.g., backslash at the 264 position 72) of a broken line, the line should be split at the 265 position one or several characters before this backslash as the 266 second last character with the backslash ("\") . In extreme case, 267 if a long line is full of backslashes, the backslashs before 268 backslash at position 73 in this line should be treated in the 269 same way as other normal characters. 271 Furthermore, whenever a document uses long line wrapping conventions 272 it MUST also include the following boilerplate text : 274 [!!! '\' line wrapping is for formatting only and adopt the conventions 275 shown in BCPXX [RFCYYYY]] 276 277 ....//Authored work 278 279 RFC Editor Note: Please replace XX and YYYY with the numbers assigned 280 for this document. 282 Figure 3 284 Figure 4 shows an example of Backslash appearing in the long line not 285 used for split line. 287 Punctuation is important. As 288 are line feeds.Some characters are special,e.g., the backslash\. 289 Don't forget. 291 Figure 4: An Example Leaf Node With a Complex String Value 293 Figure 5 shows a semantically equivalent representation of the 294 example. 296 Punctuation is important. As \ 297 are line feeds.Some characters are special,e.g., the backslash \.\ 298 Don't forget. 300 Figure 5 302 5.2. Line unwrapping 304 If line wrapping is done for formatting purposes, the line wrapping 305 in the authored work should be reversed back or unwrapped before the 306 authored work is fed into software component for validation or 307 carried in the wire. Therefore line unwrapping help remove backslash 308 and additional carriage return or line feed character and make 309 unwrapped authored work to be effectively compliant with the tool. 310 The line wrapping for formatting purpose is indicated by the above 311 boilerplate text in Figure 3. To unwrap line, the following 312 conventions must be observed: 314 o Consecutive split lines in the authored work with backslash at the 315 end of the line should be merged into one long line, the last 316 split line in Consecutive split lines should not be terminated 317 with backslash. 319 o If a backslash character ("\") doesn't appear at the end of the 320 line within authored work, it should not be stripped. 322 o If a backslash character ("\") appears at the end of the line 323 within authored work, it should be stripped. In the meanwhile, if 324 and only if it is immediately followed by a carriage return or 325 line feed character then all carriage return, line feed, and 326 whitespace characters should be stripped until the next character 327 is encountered. 329 o In extrem case, if a backslash character ("\") or space character 330 appears full of line, the full line of backslash character ("\") 331 or space character should be stripped. 333 5.3. Auto indentation and dedentation 335 Consistent indentation should be used for all authored work in the 336 I-D and RFCs, e.g., if a space or tab characters are used to index 337 the text in the long line during wraping process, the space and tab 338 characters used for indentation should be removed during unwrapping 339 process. If the new line or continuation line indented with a 340 whitespace offset of two characters during wrapping process, the 341 indentation with a whitespace offset of two characters should be 342 removed during unwrapping process. 344 6. Limitation and complexity 346 6.1. Limitations 348 All modules need to be extracted YANG modules from an Internet Draft 349 or RFC and then validated before submission in an Internet Draft. 350 However we don't have automation tool to extract authored work such 351 as YANG fragments or protocol message instance. To extract authored 352 work, the similar strings "" and "" MUST be 353 defined and populated to identify each authored work component, e.g., 354 the boilerplate text in Section 5 can be used to indicate the 355 begining of authored work. 357 Applying wrapping and unwrapping functionality to example YANG module 358 or YANG module extracted using existing tool also has limitation, 359 even introduce confusion, e.g., 361 1. The data definition description statement has long line exceeding 362 73 characters, it should be wrapped without using backslash as 363 termination point. 365 " 366 grouping link-ref { 367 description 368 "This grouping can be used to reference a link in a specific 369 network. Although it is not used in this module, it is 370 defined here for the convenience of augmenting modules."; 371 " 373 2. Another example is when a plus character ("+") is used to 374 concatenate two quoted string into one string, using backslash to 375 split the line Confuses with using a plus character ("+") to 376 split the line. 378 " 379 container dhcp-relay { 380 when "derived-from-or-self(../address-allocation-type, "+ 381 "'l3vpn-svc:provider-dhcp-relay')" { 382 description 383 "Only applies when provider is required to implement 384 DHCP relay function."; 385 } 386 " 388 6.2. Complexity 390 We can build tool to support auto wrap and auto indentation. However 391 if the tool is designed to understand various encodings, e.g., XML 392 encoding, JSON encoding or metadata annotation, it adds a lot of 393 complexity to build such tool, therefore the only choice to make tool 394 understand various encodings, is to build encoding specific tool 395 which doesn't scale well,e.g., if the tool understands metadata 396 annotation, we can decide where to insert backslash to split the 397 lines: either inserted between metadata Attributes or insert at any 398 place when the long line exceeding 73 characters limits. See more 399 complexity details in Appendix A. 401 7. Security Considerations 403 There is no direct security impact related to the documentation 404 convention for lines wrapping and indentation in authored work 405 described in this document. However, attempting to provide 406 representation of authored work using the documentation conventions 407 described in this document would have unpredictable results. The 408 risk here is that someone uses an example as a template for actual 409 authored work representation. The mandatory boilerplate text 410 provides a mitigation against this risk. 412 8. IANA Considerations 414 There are no IANA requests or assignments included in this document. 416 9. Acknowledgements 418 Thanks to Kent Watsen for discussions that kept us close to being on 419 the right track. Additional thanks to John Scudder for flagging some 420 nits, Martin Bjorklund, Charles Eckel, Robert Wilton and many others 421 for valuable comments and review, special thanks Xiongjie to help 422 support automation tool building. 424 10. Normative References 426 [I-D.ietf-netmod-rfc6087bis] 427 Bierman, A., "Guidelines for Authors and Reviewers of YANG 428 Data Model Documents", draft-ietf-netmod-rfc6087bis-20 429 (work in progress), March 2018. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 437 RFC 7950, DOI 10.17487/RFC7950, August 2016, 438 . 440 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 441 RFC 7951, DOI 10.17487/RFC7951, August 2016, 442 . 444 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 445 RFC 7952, DOI 10.17487/RFC7952, August 2016, 446 . 448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 450 May 2017, . 452 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 453 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 454 . 456 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 457 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 458 Edition)", World Wide Web Consortium Recommendation REC- 459 xml-20081126, November 2008, 460 . 462 Appendix A. Representing XML and JSON Encodings of Metadata Annotations 464 [RFC7952] section 5.1 and section 5.2 provide an encoding rule for 465 metadata annotations in XML and JSON respectively. 467 When an example XML representation of a leaf node element that 468 includes metadata attributes results in a line being longer than the 469 maximum number of characters allowed in a line of an IETF document, 470 the value of the leaf node must be split across more than one line. 472 Where possible, all line breaks should be inserted between metadata 473 attributes. Continuation lines MUST align with the first line and 474 not be indented with any whitespace. The leading and trailing 475 whitespace of each line MUST be ignored. Figure 6 gives a XML 476 example. 478 When an example JSON representation of a leaf node element that 479 includes metadata attributes starting with the "@" character results 480 in a line being longer than the maximum number of characters allowed 481 in a line of an IETF document,the value of the leaf node must be 482 split across more than one line. Continuation lines MUST align with 483 the first line and indented with one whitespace character. The 484 leading and trailing whitespace of each line MUST be ignored. 485 Figure 7 gives a JSON example. 487 Whenever this documentation convention is used, the boilerplate text 488 shown in Figure 3 MUST be present in the document using the 489 convention. 491 493 ... 494 496 Figure 6: An XML Example Leaf Node With Metadata Split Across Lines 498 "cask": { 499 "@": { 500 "example-org-example-last-modified:last-modified":\ 501 "2015-09-16T10:27:35+02:00" 502 }, 503 ... 504 } 506 Figure 7: A JSON Example Leaf Node With Metadata Split Across Lines 508 Appendix B. Auto-wrapping tool code 510 We provide examples of python code for aspects of line wrapping and 511 unwrapping algorithms. There may be other implementation methods 512 that are faster in particular operating environments or have other 513 advantages. These implementation notes are for informational 514 purposes only and are meant to clarify the this specification for 515 line wrapping and unwrapping. 517 #!/usr/bin/env python2.7 518 # -*- coding: utf-8 -*- 519 """Qin Wu, 2018-06-02 520 Autowrapper.py uses Text Wrap Module as library and support auto wrap and auto indent 521 two functionalities. 522 (1)Lines with "\" in position 72 have been handled. 523 (2)Lines with space in position 73 have been handled. 524 (3)A line of "\" has been handled. 525 (4)A line of space has been hanled. 526 https://github.com/sunseawq/auto-wrap-indent/blob/master/autowrapper.py 527 Text Wrap module provides two convenience functions, wrap() and fill(), as well as 528 TextWrapper, the class that does all the work, and a utility function dedent(). If 529 you're just wrapping or filling one or two text strings, the convenience functions 530 should be good enough; otherwise, you should use an instance of TextWrapper for 531 efficiency. 533 https://github.com/python/cpython/blob/2.7/Lib/textwrap.py 534 """ 535 import textwrap 536 import string, re 537 import argparse 538 import os.path 539 import sys, getopt 541 def indent(text, prefix, predicate=None): 542 """Adds 'prefix' to the beginning of selected lines in 'text'. 544 If 'predicate' is provided, 'prefix' will only be added to the lines 545 where 'predicate(line)' is True. If 'predicate' is not provided, 546 it will default to adding 'prefix' to all non-empty lines that do not 547 consist solely of whitespace characters. 548 """ 549 if predicate is None: 550 def predicate(line): 551 return line.strip() 553 def prefixed_lines(): 554 for line in text.splitlines(True): 555 yield (prefix + line if predicate(line) else line) 556 return ''.join(prefixed_lines()) 558 def auto_wrap(input_file, dst_file): 559 finput=open(input_file, "r") 560 alllines=finput.readlines() 561 finput.close() 562 foutput = 0 563 output_file = dst_file 564 foutput = open(output_file, 'a') 565 for eachline in alllines: 566 bc = textwrap.fill(eachline,73) 567 tmplines = bc.split('\n') 568 tmplen = len(tmplines) 569 if tmplen == 1 : 570 foutput.writelines(bc) 571 foutput.writelines('\n') 572 else : 573 i = 0 574 while i < tmplen-1 : 575 foutput.writelines(tmplines[i]) 576 foutput.writelines('\\') 577 foutput.writelines('\n') 578 i += 1 579 foutput.writelines(tmplines[tmplen-1]) 580 foutput.writelines('\n') 581 foutput.close 583 def auto_unwrap(input_file, dst_file) : 584 finput=open(input_file, "r") 585 alllines=finput.readlines() 586 finput.close() 587 foutput = 0 588 output_file = dst_file 589 foutput = open(output_file, 'a') 590 for eachline in alllines: 591 if eachline.endswith('\\\n') : 592 eachline = eachline.strip('\\\n') 593 foutput.writelines(eachline) 595 def auto_wrap_indent(input_file, dst_file,width): 596 finput=open(input_file, "r") 597 alllines=finput.readlines() 598 finput.close() 599 foutput = 0 600 flag_add = 0 601 backslashpos = 0 602 output_file = dst_file 603 foutput = open(output_file, 'a') 604 for eachline in alllines: 605 backslashpos = eachline.rstrip('\\\n').rfind('\\',0,width) 606 '''handle backslash at position 72''' 607 if (backslashpos == width-1) : 608 print("backslash appear at the end of the line, 609 the line is wrapped at the position one or multiple characters 610 before the backslash") 611 bc = textwrap.fill(eachline,width-1) 612 else : 613 bc = textwrap.fill(eachline,73) 614 '''handle space at position 71,72,73''' 615 if eachline.rstrip('\n').rfind(' ',width-2,width) == width-2 : 617 bc = bc[:width-2] + ' \n' + bc[width-1:] 618 if eachline.rstrip(' \n').rfind(' ',width-2,width) == width-1 : 619 bc = bc[:width-1] + ' \n' + bc[width:] 620 if eachline.rstrip(' \n').rfind(' ',width-2,width+1) == width : 621 bc = bc[:width] + ' \n' + bc[width+1:] 622 tmplines = bc.split('\n') 623 tmplen = len(tmplines) 624 if tmplen == 1 : 625 foutput.writelines(bc) 626 foutput.writelines('\n') 627 else : 628 flag_add = 0 629 i = 0 630 while i < tmplen-1 : 631 if(flag_add == 1) : 632 tmplines[i] = indent(tmplines[i], ' ') 633 foutput.writelines(tmplines[i]) 634 foutput.writelines('\\') 635 flag_add = 1 636 foutput.writelines('\n') 637 i += 1 638 if(flag_add == 1) : 639 tmplines[i] = indent(tmplines[i], ' ') 640 foutput.writelines(tmplines[tmplen-1]) 641 foutput.writelines('\n') 642 foutput.close 644 def auto_unwrap_dedent(input_file, dst_file) : 645 finput=open(input_file, "r") 646 alllines=finput.readlines() 647 finput.close() 648 foutput = 0 649 flag_del = 0 650 flag_space = 0 651 output_file = dst_file 652 foutput = open(output_file, 'a') 653 for eachline in alllines: 654 print(eachline) 655 if(flag_del == 1) : 656 eachline = eachline[2:] 657 if eachline.endswith('\\\n') : 658 flag_del = 1 659 eachline = eachline.rstrip('\\\n') 660 if eachline == '': 661 flag_del = 0 662 else : 663 flag_del = 0 665 if eachline == '\n' : 666 continue 667 foutput.writelines(eachline) 669 if __name__ == "__main__": 670 auto_wrap("in-1.txt","out-1.txt") 671 auto_unwrap("out-1.txt", "out-2.txt") 672 auto_wrap_indent("in-1.txt","out-1.txt",73) 673 auto_unwrap_dedent("out-1.txt", "out-2.txt") 675 Authors' Addresses 677 Qin Wu 678 Huawei 679 101 Software Avenue, Yuhua District 680 Nanjing, Jiangsu 210012 681 China 683 Email: bill.wu@huawei.com 685 Adrian Farrel 686 Juniper Networks 688 Email: afarrel@juniper.net 690 Benoit Claise 691 Cisco Systems, Inc. 692 De Kleetlaan 6a b1 693 1831 Diegem 694 Belgium 696 Phone: +32 2 704 5622 697 Email: bclaise@cisco.com