Kent Watsen <[email protected]> wrote:
>
>
> >> Those are torture tests, but they due illustrate the one case where having
> >> the '\\n' on the fold column would've been illegal input (and hence the '\'
> >> was replaced with a 'x'). Great for internal algorithm validation, but
> >> perhaps unnecessary for the example in the text. Or maybe enhance the
> >> comments above these lines to explain why they're there?
> >
> > I suggest you remove this.
>
> Okay.
>
>
> >> > I like the algorithm in the other draft better - it had variable
> >> > placement of the line break ("\\n" sequence), and variable
> >> > indentation.
> >>
> >> How can you automated variable placement of the line-break, assuming no
> >> awareness of the file format? Additionally, be aware that variable '\n'
> >> placement would necessitate pre-scanning the file to ensure *no* line
> >> ends in a '\\n', as opposed to just the lines that need folding.
> >
> > I envision this format being used not just by a program, but also by
> > humans trying to construct nice looking examples.
>
> I really hope humans don't try to do this manually, as the results are
> error-prone, and it isn't consistent with the goal of integrating validation
> in the build scripts that compile the drafts, for which automated-folding
> is needed (see section 3.1).
I disagree. I often use my own markup in example files so that I can
validate the examples with tools, and then run a script that turns the
markup into newlines (in the future: '\' + newline).
For example:
<namespace><!-- PPL
-->urn:ietf:params:xml:ns:yang:ietf-yang-types</namespace>
turns into:
<namespace>\
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
(the <!-- PPL --> is my own markup).
Compare with
<namespace>urn:ietf:params:xml:ns:yang:ietf-yang-types</n\
amespace>
Not sure if this qualifies as "manual folding" or not.
> I'm not saying that manual-folding shouldn't
> be possible, I'm saying that it is ill-advised, and we shouldn't go out of
> our way to support it.
I don't think it is difficult to support variable placement of the
linebreak. It is already specified in the other draft.
> I do not support variable placement of the
> line-break.
>
> [Note: indentation of the beginning of the line is a different issue, and
> one that I actually support, assuming it is easily automatable]
>
>
> > Also, I would prefer a description of the format, rather than of one
> > algorithm that produces the format.
>
> Okay, we will look into it.
>
>
> >> >> >> - handle two special case on backslash and space at the end of
> >> >> >> broken
> >> >> >> line in yang-xml-doc-conventions.
> >> >> >> - propose to use <WRAPPED TEXT BEGIN><WRAPPED TEXT END> to extract
> >> >> >> artwork from I-Ds.
> >> >> >
> >> >> > The artwork draft proposes only a header, which means that it is not
> >> >> > quite clear where the artwork ends.
> >> >>
> >> >> Interesting point, but I think that artwork-framing is a different
> >> >> problem
> >> >> from artwork-folding. If the goal is to support extracting artwork from
> >> >> txt-based RFC scripts, regardless if the artwork is folded or not, then
> >> >> we
> >> >> could level-up this draft to that role, while still supporting folding.
> >> >>
> >> >> If we were to add a footer, maybe something like this:
> >> >>
> >> >> ===padding=== End Folding per BCP XX (RFC XXXX) ===padding===
> >> >>
> >> >> where the "padding" fills in '=' characters until the max-line width is
> >> >> reached (same as how the header is done).
> >> >
> >> > Ok.
> >>
> >> I assume that you're okay-ing the proposed footer, but the real question is
> >> if we should expand the scope of this draft to include artwork-framing
> >> also?
> >
> > I think I would prefer if there is also a footer.
>
> Why? Do you propose the same for all artwork, regardless if it's been folded
> or not? To me, these are different issues.
Hmm, good point. Maybe ignore for now.
/martin
> >> >> >> In the artwork draft, section 5.3, you write:
> >> >> >>
> >> >> >> This line is self-describing in
> >> >> >> three ways: use of '\' character, identification of BCP/RFC, and
> >> >> >> identification of what the maximum line length is for the artwork.
> >> >> >>
> >> >> > I was confused about this maximum line length; it seems you define the
> >> >> > maximum line length ot be 53, but that seems too limiting, and indeed
> >> >> > in the example in 5.4 the max line length is 69. (BTW, the example is
> >> >> > missing in the draft, as is the shell script in Appendix A). In any
> >> >> > case, I don't see how the header identifies the max line length.
> >> >>
> >> >> The draft says that the *minimal* header string is 53-characters). We
> >> >> can make it less if needed, but it involves needing to fold the header
> >> >> itself, which could become messy. Thoughts?
> >> >>
> >> >> Per the line just before the one quoted above, this line is '=' padded
> >> >> on both sides until reaching the max value. Apparently, this isn't
> >> >> clear enough in the text, or do you think it's okay now?
> >> >
> >> > The draft says:
> >> >
> >> > The header is two lines long.
> >> >
> >> > The first line is the following 53-character string
> >> >
> >> > This is what made me confused. I now understand that the idea is to pad
> >> > with '='.
> >>
> >> Right, the full sentence is:
> >>
> >> The first line is the following 53-character string that has been
> >> padded with roughly equal numbers of equal ('=') characters to reach
> >> the artwork's maximum line length.
> >>
> >> So, leave as is for now?
> >
> > Well ... I don't think this text is even correct... The section
> > describes the header with the first line being 53 characters. But
> > that is just an example. Maybe:
> >
> > The first line is an N-character string on the following form:
> >
> > === NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===
> >
> > where N is the artwork's maximum length (the minimum length is
> > 53). The string is padded with roughly equal numbers of equal
> > ('=') characters in the beginning and end to reach the artwork's
> > maximum line length.
>
> Yes, this is better
>
>
> > ... but as I wrote, I'd prefer a variable-length format.
>
> Understood, being discussed above.
>
>
> > /martin
>
> Kent // contributor
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
