Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
Martin Bjorklund <mbj@tail-f.com> Thu, 28 June 2018 06:08 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0282D130E09 for <netmod@ietfa.amsl.com>; Wed, 27 Jun 2018 23:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFZ2yMEmAlbZ for <netmod@ietfa.amsl.com>; Wed, 27 Jun 2018 23:08:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DCB36126F72 for <netmod@ietf.org>; Wed, 27 Jun 2018 23:08:14 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EE0E41AE0141; Thu, 28 Jun 2018 08:08:13 +0200 (CEST)
Date: Thu, 28 Jun 2018 08:08:13 +0200
Message-Id: <20180628.080813.2173042785762431704.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: rwilton=40cisco.com@dmarc.ietf.org, bill.wu@huawei.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <70F6E49F-C83F-4C38-92CB-860631B4C050@juniper.net>
References: <B8F9A780D330094D99AF023C5877DABA9AEB4274@nkgeml513-mbx.china.huawei.com> <194df0e3-038d-d0cc-ea45-f5448fc10562@cisco.com> <70F6E49F-C83F-4C38-92CB-860631B4C050@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6xyYPir0GiIY31eanM9gYDP-38A>
Subject: Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 06:08:18 -0000
Kent Watsen <kwatsen@juniper.net> wrote: > All, I just posted -06 that addresses some comments from Rob, Martin, > and Jonathan. I realize that there are still open issues, but a rapid > iteration for some of these things seems like it might be good: > https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-06. > > > Hi Robert, > > > A couple of comments: > > > > 1) Section 4.2 suggests using groupings to presumably avoid folding. I > > don't really support this as a strategy, since I think that groupings > > are overused and I think that they obfuscate the true structure of a > > YANG module, that can only be recovered by recompiling the module with > > the groupings expanded, or looking at the tree output. Really, I think > > that an ideal solution would be to somehow have RFCs support longer > > lines for files like YANG - e.g. if I could choose any value without > > regard for backwards compatibility I would probably choose 120 > > characters instead. > > I removed the word "grouping" from the text. Now it says "...call outs, > such as functions". > > > > > 2) The proposed solution always left indents the wrapped line. Often for > > artwork (e.g. a YANG tree diagram), where whitespace is not significant, > > and the wrapping is relatively minor, then right indenting the wrapped > > line can make the results look more visually readable. > > > > E.g. I think that this is slightly easier to read: > > > > module: ietf-flexible-encapsulation > > augment /if:interfaces/if:interface/if-cmn:encapsulation\ > > /if-cmn:encaps-type: > > +--:(flexible) > > +--rw flexible > > +--rw match > > | +--rw (match-type) > > | +--:(default) > > | | +--rw default? empty > > | +--:(untagged) > > | | +--rw untagged? empty > > | +--:(dot1q-priority-tagged) > > | | +--rw dot1q-priority-tagged > > | | +--rw tag-type? dot1q-types:dot1q-\ > > tag-type > > | +--:(dot1q-vlan-tagged) > > | +--rw dot1q-vlan-tagged > > > > rather than: > > > > module: ietf-flexible-encapsulation > > augment /if:interfaces/if:interface/if-cmn:encapsulation\ > >/if-cmn:encaps-type: > > +--:(flexible) > > +--rw flexible > > +--rw match > > | +--rw (match-type) > > | +--:(default) > > | | +--rw default? empty > > | +--:(untagged) > > | | +--rw untagged? empty > > | +--:(dot1q-priority-tagged) > > | | +--rw dot1q-priority-tagged > > | | +--rw tag-type? dot1q-types:dot1q-\ > >tag-type > > | +--:(dot1q-vlan-tagged) > > | +--rw dot1q-vlan-tagged > > > > The placement of the indents in the example above would be impossible > to automate - they're too artsy ;) However, it should be possible > to automate a variable indent that lines up with the first printable > character on the previous line. Something like this: > > module: ietf-flexible-encapsulation > augment /if:interfaces/if:interface/if-cmn:encapsulation\ > /if-cmn:encaps-type: > +--:(flexible) > +--rw flexible > +--rw match > | +--rw (match-type) > | +--:(default) > | | +--rw default? empty > | +--:(untagged) > | | +--rw untagged? empty > | +--:(dot1q-priority-tagged) > | | +--rw dot1q-priority-tagged > | | +--rw tag-type? dot1q-types:dot1q-\ > tag-type > | +--:(dot1q-vlan-tagged) > | +--rw dot1q-vlan-tagged > > [note: previous line indent matching is beyond what can be accomplished > via a simple `sed` or `awk` one-liner]. > > Regardless if automated or manual, I think the indent rule needs to be > rather strict. In particular, arbitrary per-line indent can lead to > lossy round-tripping (unfolding errors), unless we introduce a rule > saying that the source artwork MUST NOT have a space (' ') character > that occurring on a fold column. Otherwise the following might happen. > > ORIG: > > example: > This very long line happens to have a space character immediately after the fold column."; > > > FOLDED: *** doesn't matter the indentation strategy *** > > ===== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===== > example: > This very long line happens to have a space character\ > immediately after the fold column."; > > > UNFOLDED (using alg that chomps all leading whitespace): > > example: > This very long line happens to have a space characterimmediately after the fold column."; > > > Note the error in the unfolded version. I think disallowing > whitespace characters on the fold column in the source artwork is > overly limiting, spaces being so commonly used. But with variable placement of the '\' character you can do: This very long line happens to have a space character \ immediately after the fold column."; or This very long line happens to have a space \ character immediately after the fold column."; so I'm not sure that disallowing space at the fold column is a problem. Note that even with this, your original "one-liner sed" still produces valid results, so if you just want a simple folding program you can use that. /martin > The only way I > can think to preserve the space character is to have a fixed > indent rule (e.g., some hardcoded column number, or always use > the same indent as previous line, or the same as the previous > line plus some fixed offset). Given a clear rule, the unfolding > alg can chomp just the right amount of whitespace out, leaving > the any remaining whitespace, so the round-trip result is loss-less. > > > > Rob > > Kent // contributor > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… joel jaeggli
- [netmod] Call for adoption request of draft-kwats… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Qin Wu
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund
- Re: [netmod] Call for adoption request of draft-k… Bob Harold
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Kent Watsen
- Re: [netmod] Call for adoption request of draft-k… Robert Wilton
- Re: [netmod] Call for adoption request of draft-k… Martin Bjorklund