Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04

Robert Wilton <> Fri, 29 June 2018 09:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0024130DC2 for <>; Fri, 29 Jun 2018 02:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2RdPAiswD7oC for <>; Fri, 29 Jun 2018 02:15:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB25B128BAC for <>; Fri, 29 Jun 2018 02:15:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3309; q=dns/txt; s=iport; t=1530263759; x=1531473359; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=++Zac3pC+B3ph4+9GLByxDd0fpjsnl3k7f7vxQ1GjYY=; b=USFOZZ8oK3EKxzuhLgIVUxTPufh2PDMvhxWQ/QIS7GHmI+JGHu0mJFZa BOwN9g3HozU5tg7RYh6EIDHdJOFHcorvppHaaHEWiANm7+6rWganPynJM R86UsymVxz/05C7PZaaQmd+412YRQmouyNwjN4pErCMQ6G9pwMI0YjfxV c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQAT+DVb/xbLJq1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYUYEoQhiGONOwgilxsLhGwCgz84FAECAQECAQECbSiFNwE?= =?us-ascii?q?FHQYVUQsOCgICJgICVwYBDAgBAReDBYIArWiCHIRbg3SBJIELiTg/gTYMgly?= =?us-ascii?q?BKIZTglUCjQiMOwmPFQaID4VCjC6FT4FYIYFSMxoIGxWDJYJKjgc+kTcBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,285,1526342400"; d="scan'208";a="4800681"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 09:15:56 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id w5T9FuE1030343; Fri, 29 Jun 2018 09:15:56 GMT
To: Kent Watsen <>, Qin Wu <>, "" <>
References: <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Fri, 29 Jun 2018 10:15:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [netmod] Call for adoption request of draft-kwatsen-netmod-artwork-folding-04
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jun 2018 09:16:01 -0000

On 29/06/2018 00:03, Kent Watsen wrote:
> Hi Robert,
>>>> 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.
>>> The placement of the indents in the example above would be impossible
>>> to automate - they're too artsy ;)
>> They are just right indented, so it is pretty easy to figure out?  E.g.
>> start at  (Max line length - number of wrapped chars)
> My bad, I didn't catch that they were right-indented before.  Hmmmm,
> interesting idea, worth keeping in mind.  I see how it produces good
> results sometimes, but it also seems like it could produce some results
> that are not as good as indenting to the first whitespace character
> from the previous line.
Sure, that decision on how to intend the wrapped line could be down to 
the tool that is performing the folding, perhaps predicated by user 
input or the type of diagram that is being folded.

E.g. I agreed with Martin's comments that it is better to specify the 
required behavior rather than describe a specific algorithm on how it is 

>>> 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.   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.
>> There other ways to solve this, at a slight increase in complexity.
>> E.g. You could use two marker characters, e.g. as below, where
>> everything between and including the two '\' characters is stripped.
>> Simple folding tools could just put the second '\' at the beginning of
>> the next line, or at a fixed column,  more sophisticated tools could put
>> more effort into making it more readable, but still preserve the ability
>> to get the exact source back out again.
>>            |     |  +--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
> Clever!  Having both seems to resolve many issues, and it might be within
> reach of a `sed` one-liner again.  The only issue might be readability,
> since it's so different than the time-aged convention...
Only one thin character different ;-)

Perhaps it could be the start of a new convention that is a bit more 
flexible, explicit, and robust ...


>> Rob
> Kent // contributor