[rfc-i] Numbering and counting things (was: Re: New Version Notification for draft-flanagan-plaintext-00.txt)

Phillip Hallam-Baker phill at hallambaker.com
Wed Jun 25 05:05:19 PDT 2014


+1

Citing a paragraph makes sense, a line number rarely adds additional
information.

Further since the documents most likely to have fine grained citations are
others from the same document set, being over specific with line numbers is
a hassle.

Further, I can do paragraph level citations in an evening with a glass or
two of port. Doing line level citations would be an utter pain.


I don't see the need for a specific ban on page long paragraphs as that is
a corner case unlikely to arise and trying to ban it would require us to
define 'page'.


Actually there is a workflow tool I have around that allows comments to be
attached at paragraph level, will have to dust it off...



On Wed, Jun 25, 2014 at 7:53 AM, John C Klensin <john-ietf at jck.com> wrote:

>
>
> --On Tuesday, June 24, 2014 10:39:29 -0700, Joe Touch
> <touch at isi.edu> wrote:
>
> > On 6/24/2014 10:04 AM, Dearlove, Christopher (UK) wrote:
> >> No one I've noticed has suggested that all formats should
> >> have line numbers, be easily printable etc.
> >>
> >> Just that one format should have those properties.
> >
> > I doubt that would be useful - unless that format were the
> > sole  canonical one.
>
> As others have suggested, while I'm not wild about it as a
> style, one could decide to automatically number paragraphs,
> either from the beginning of the document or within numbered
> sections.  Paragraphs are reasonably well defined even if the
> definition turns out in practice to be equivalent to "[flowed]
> line" in running text, and are more or less equivalent to the
> "t" element in XML2RFC format.
>
> One would then have to have a style rule prohibiting "page"-long
> paragraphs and to think very carefully about what to do about
> various types of lists within an XML2RFC paragraph/ list element
> and pseudo-paragraphs constructed with vspace elements.   But,
> unlike line numbers, it would be meaningful and
> reader-format-independent if the cases were examined carefully
> and stylistic rules made, documented, and then used and enforced
> consistently.
>
> Also, in a later note:
>
> > Any item that has more than one representation begs the
> > question of  "which is normative?" *when* (not if) the text
> > and figure differ.
>
> Yep.  And when other things differ as well, even if, as above,
> one can establish conventions that make the differences trivial
> in some cases.
>
> > When we're writing a spec, IMO the text ought to be normative,
> > and the  text alone ought to be sufficient (even if tedious).
>
> And that, in a sentence, is one of two major problems with
> declaring that the marked-up (xml2rfc) version is normative and
> that none of the normally-human-readable presentation versions
> are.
>
>     john
>
> p.s. One has better be _really_ careful about notions based on
> counting bytes, octets, or similar units in the presence of "use
> UTF-8", especially if that comes without a clear and
> consistently used and enforced rule about normalization.
>
> p.p.s. Those who are outraged about the idea of losing normative
> ASCII art should remember that RFCs with only non-ASCII
> illustrations have been allowed for a rather long time (see,
> e.g., RFC 12).  It has required exceptional permission of the
> RFC Editor but one plausible possibility would be to identify
> cases for which the exception would be automatic.
>
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140625/bc0c5665/attachment.html>


More information about the rfc-interest mailing list