[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 --
- [rfc-i] Pagination and the xml2rfc v3 vocabulary … Larry Masinter
- [rfc-i] Pagination and the xml2rfc v3 vocabulary … Nico Williams