[rfc-i] Pagination and the xml2rfc v3 vocabulary // comment on Publication Formatter SOW

nico at cryptonector.com (Nico Williams) Tue, 17 February 2015 22:26 UTC

From: "nico at cryptonector.com"
Date: Tue, 17 Feb 2015 16:26:23 -0600
Subject: [rfc-i] Pagination and the xml2rfc v3 vocabulary // comment on Publication Formatter SOW
In-Reply-To: <2089DF41-CDD7-4199-97E7-792CE44E426B@adobe.com>
References: <2089DF41-CDD7-4199-97E7-792CE44E426B@adobe.com>
Message-ID: <CAK3OfOgLUMM_ru+hN33=3_zu7BnU+3b=irOaKYggjUV0jptPJw@mail.gmail.com>

On Wed, Feb 11, 2015 at 10:32 PM, Larry Masinter <masinter at adobe.com> wrote:
> Isn?t the main reason for not investing in tools to let authors control
> pagination directly is that the process of RFC production (removing
> RFC-editor ?NOTE? for example, or just fixing punctuation) will likely cause
> some cases of change of pagination, so authors putting direct page breaks is
> likely to fail.

I'm happy with the mechanism for affecting pagination that Heather
described (split figures/artwork).  It will work for the RFC-Editor.

It might not work so well for I-D authors, but maybe we (I-D authors)
shouldn't care so much and that's that.

> Whatever markup is added needs to not make things worse if pagination
> changes.

All markup proposed to date would be safe to ignore.  As this is XML,
elements in other namespaces could be ignored by the processor used by
the RFC-Editor, but understood by the xml2rfc that we use.

> I sent in a comment on the Publication-Formatter SOW that perhaps I should
> have sent to this list?
>
> Date: Wednesday, January 28, 2015 at 11:31 AM
> To: "'iaoc-tmc at ietf-bids.org'"
> Cc: Tony Hansen, Leonard Rosenthol, Matthew Hardy
> Subject: comment on Publication-Formatter-SOW-04
>
> 1.  Publication Formatter
>
>
> <https://iaoc.ietf.org/documents/Publication-Formatter-SOW-04.pdf>
>
>
>
> https://tools.ietf.org/html/draft-hansen-rfc-use-of-pdf
>
> notes there are different requirements for xml2rfc processing for Internet
> Drafts and for RFCs.
>
>
>
> Requiring support of the tool for Linux, Windows and Mac and the exact same
> tool for I-Ds and RFCs will substantially reduce the options and may make it
> difficult to meet all requirements.

Is that really so?  First, it's trivial nowadays to make a web "API"
for xml2rfc, so that multi-platform support is easy (all you need is a
way to POST and get back the result; if need be users can use a
browser).

Second, the lion's share of the work here is platform-neutral, and the
UI can be coded in any of many platform-neutral frameworks.

> RFC Editor tools should be required to run on platform RFC editor has, which
> might reasonably be limited to compatibility with one of Windows, Mac,
> Linux, but not necessarily all three.

Some of the tools for the RFC-Editor are likely to be tools for the
Internet community at large.  Support for non-RFC-Editor authors may
not be a requirement for those tools, but it's worth thinking about.

Nico
--