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 (CEST)
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
>