Ladislav Lhotka <[email protected]> wrote: > On Tue, 2018-10-23 at 16:27 +0200, Martin Bjorklund wrote: > > Ladislav Lhotka <[email protected]> wrote: > > > On Tue, 2018-10-23 at 14:45 +0100, Adrian Farrel wrote: > > > > Hi, > > > > > > > > 1. I think you miss the point. While example XML/JSON YANG is included > > > > in > > > > drafts, and while the authors are allowed to produce those drafts as txt > > > > files, > > > > or while the authors want to achieve pretty-to-read formatting, this > > > > work > > > > falls > > > > into the scope of those authors. > > > > > > The folding of long lines should be done as the very last (automatic) step > > > before the document gets published. Doing it earlier means that the source > > code > > > in this folded form can be (accidentally) further edited, which can lead > > > to > > > inconsistencies. > > > > I will use folding e.g. for instance document examples in XML and > > JSON. > > > > My plan is to keep the example files with manually added breaks in my > > repo, and as part of validation run a script that unfolds the > > examples, and then validate the result. The reason for this is that I > > think readbility of the examples is important. > > This seems backwards to me. If you need to edit such an example, you may have > to > remove the backslashes, reformat and insert them again. > > If it's not possible to fold lines according to the syntax of a given > language, > I'd prefer to keep the original lines as long as possible and rely on an > automatic procedure just before the final document is rolled out.
Fortunately, the draft allows us both to work the way we prefer. /martin > > Lada > > > > > > > /martin > > > > > > > > > > > > As long as the document is being moved around and edited, it would be > > > better > > to > > > keep the source code untouched. > > > > > > Lada > > > > > > > > > > > 2. Yes, the authors discussed the <sourcecode> element and agreed that > > > > it > > will > > > > be in scope. > > > > > > > > However, we are all sort of waiting for xml2rfc v3 and pending > > > > completion, > > we > > > > want to move this forward for v2 that is in use today. > > > > > > > > (More than) Happy to come back and revisit this issue when v3 is > > > > deployed. > > > > > > > > Thanks, > > > > Adrian > > > > > > > > > -----Original Message----- > > > > > From: netmod [mailto:[email protected]] On Behalf Of Ladislav > > Lhotka > > > > > Sent: 23 October 2018 14:24 > > > > > To: [email protected] > > > > > Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork- > > folding- > > > > > 08 > > > > > > > > > > On Tue, 2018-10-23 at 14:40 +0200, Ladislav Lhotka wrote: > > > > > > Hi, > > > > > > > > > > > > I support the adoption. > > > > > > > > > > > > Comments: > > > > > > > > > > > > 1. My general feeling is that such technicalities should be handled > > > > > > by > > > > > > the RFC editor and/or tools rather than YANG module and RFC > > authors. > > > > > > > > > > > > 2. xml2rfc v3 introduced a new element, <sourcecode>, that is > > > > > > intended > > > > > > for source code inclusion. This document should therefore cover > > this > > > > > > element as well (primarily?). One problem with it is that the > > xml2rfc > > > > > > tool automatically adds the <CODE BEGINS> and <CODE ENDS> > > > > > > markers, > > > > > > which interferes with YANG convention specified in RFC 8407, > > > > > > sec. 3.2. I have already raised a question about this in the > > > > > > xml2rfc-dev mailing list. > > > > > > > > > > Update: using the "name" attribute with <sourcecode> does the right > > thing. > > > > > > > > > > <sourcecode name="[email protected]"> > > > > > ... > > > > > </sourcecode> > > > > > > > > > > results in > > > > > > > > > > <CODE BEGINS> file "[email protected]" > > > > > ... > > > > > <CODE ENDS> > > > > > > > > > > Lada > > > > > > > > > > > Lada > > > > > > > > > > > > Lou Berger <[email protected]> writes: > > > > > > > > > > > > > All, > > > > > > > > > > > > > > This is start of a two week poll on making > > > > > > > draft-kwatsen-netmod-artwork-folding-08 a working group > > > > > > > document. Please send email to the list indicating "yes/support" > > > > > > > or > > > > > > > "no/do not support". If indicating no, please state your > > reservations > > > > > > > with the document. If yes, please also feel free to provide > > comments > > > > > > > you'd like to see addressed once the document is a WG document. > > > > > > > > > > > > > > The poll ends Oct 1. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Lou (and co-chairs) > > > > > > > > > > > > > > _______________________________________________ > > > > > > > netmod mailing list > > > > > > > [email protected] > > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > > > > > Ladislav Lhotka > > > > > Head, CZ.NIC Labs > > > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > > > Ladislav Lhotka > > > Head, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
