Re: [xml2rfc] xml2rfc Digest, Vol 101, Issue 9

[Henrik Levkowetz <[e-mail]>]

Hi John,

Some comments on what the current v3 implementation does for
each of the points below:

On 2019-07-15 06:37, John C Klensin wrote:
> 
> On 12.07.2019 19:44, Julian Reschke wrote:
>>> ...
>>> So then who is in charge to decide whether the day of month
>>> is inserted?
>>> 
>>> 1) The author? (in that case, the citation libs would need to
>>> drop the date for internet drafts)
>>> 
>>> 2) The processor? (in which case it'll need an extra signal
>>> for April 1st RFCs)
>>> 
>>> This may have been not so important in the past. But in the
>>> v3 world (AFAIU), there will be no manual post-processing
>>> step anymore, so whatever the formatter emits will be what
>>> people see... ...
>> 
>> Proposed extension:
>> <https://greenbytes.de/tech/webdav/rfc2629xslt.html#ext-rfc262
>> 9.date>
>> 
>> Example:
>> <https://greenbytes.de/tech/webdav/rfc2616.html#RFC2324>
> 
> I think this (including the proposed extension) is being made
> unnecessarily complicated and that 
> 
>    x:include-day" ("true", "false") 
> 
> as proposed does not do the right thing.
> 
> The system clearly knows whether it is generating I-Ds or RFCs.
> It clearly has to in order to generate different boilerplate.
> So, 
> 
> for RFCs:
> (i) The front page is always without a day-of-month unless some
> attribute or other flag is present (for the April 1 case).

With current v3, this is controlled by the RPC by leaving out or
filling in the day in the document <date> entry.  The renderers
render the date with/without day accordingly.

(This diverges from RFC 7998, which in Section 5.2.3
(https://tools.ietf.org/html/rfc7998#section-5.2.3) 
removes the RFC Editor's choice and sets out to enforce that all
date components always be specified.  Note that when the XML
format becomes the published archival format, it becomes more
important than earlier to retain the RFC Editor's freedom to
specify a publication date with or without date, or possibly even
month, in the XML date element.  See also: 
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-4.4.1 )

> (ii) References use whatever content and format the Style Guide
> says what they use.  If it is "Month Year" then maybe an
> attribute should permit an exception to that, but I doubt it
> will be used very often if ever.

Current v3 simply uses the elements provided in the reference
entry (which follows the front page dates for RFCs).

> (iii) The Style Guide should be reviewed to make sure that a
> reference to a document published in a language other than
> English and whose preferred date is not in English (and perhaps
> not even in Gregorian calendar) comes out the way the RFC Editor
> wants it.  I am largely agnostic as to what that is, but it
> should probably be sorted out and specified now because it may
> affect the markup.  I would strongly encourage people to think
> about this using an example that is not drawn from Latin script
> or even a European script.

Current v3 has no support for alternative non-Gregorian dates
or non-latin date renderings.

(Adding this seems like a good idea, to me.)

> For I-Ds (and any other non-RFCs of interest):
> 
> (i) The front page is "month day, year".  I note that the
> submission tool will reject an I-D submission if the day number
> is not present.   If the xml2rfc developers want to provide
> extra generality by including an attribute to suppress the day,
> go for it, but I believe the only thing that could make that
> necessary is automatic date (including day number) generation
> when <date> is used without all of "year", "month", and "day"
> attributes.

The current code to handle various combinations of missing <date>
components is complex, but if it was possible to get a draft through
submission with year and month, but without a day component, then
the current v3 will honour that lack of day, and render only year
and month.  What you say about a possible attribute to suppress
the day seems correct to me.

> (ii) References simply use whatever authors supply.  If a day
> number is specified, it appears.  If it isn't, it doesn't.  Note
> that this principle is important for another reason and that is
> at least one reason why we don't make up date values when the
> <date> element is specified without attributes: some journals
> publish only once a year and traditional books generally do not
> specify even month information.  So what the author specifies,
> whether it be a year, a year and month, or a year, month, and
> day goes into the output.

This matches what the current v3 does, except that the current
specification is unworkable for some dates that are approximate.
For more on this see:
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-09#section-4.1.3.2

> 
> (iii) Finally, I think that using different date formats in
> different places (I'm talking about the format here, not whether
> or not a day number appears) is probably an invitation to
> trouble long-term.  Perhaps, with the likely exception of the
> RFC header (and maybe footer), it is time to recognize that,
> along with other changes for the new format, RFCs are becoming
> "international" enough that it would be appropriate to go with
> ISO 8601 dates and be done with it, both in whatever in
> generated by markup and in Style Guide recommendations about any
> dates that might appear in running text.   Or not.

The current v3 formatter does not do this.

(Personally, I have mixed feelings on this; as long as the local
numeric date format in use across the countries of the world vary as
much as it does (https://en.wikipedia.org/wiki/Date_format_by_country),
it seems to me that Georgian date rendering probably should use
month names in order to be easily assimilated by human readers.)


Best regards,

	Henrik