xml2rfc

xml2rfc copied to clipboard

Description

Currently the HTML output captures the version of xml2rfc in the <meta> element, e.g., <meta content="xml2rfc 3.17.4" name="generator"> and also in a comment:

<!-- Generator version information:
  xml2rfc 3.17.4
    Python 3.9.15
    ConfigArgParse 1.5.3
    google-i18n-address 3.0.0
    intervaltree 3.1.0
    Jinja2 3.1.2
    lxml 4.9.0
    platformdirs 3.8.0
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    wcwidth 0.2.5
    weasyprint 56.1
-->

When the HTML output is created, it would be good to also have a timestamp of publication (that is, propagate the timestamp from the prepTime attribute found in the XML file) and a timestamp that captures when the HTML was rendered. If the HTML is then rerendered in the future, then these two timestamps will capture that info (that is, the publication timestamp will be older than the rendering timestamp). See the RPAT meeting notes.

Code of Conduct

• [X] I agree to follow the IETF's Code of Conduct

With the change proposed in #1033, xml2rfc will add a new meta tag with name created. This content for the meta tag will have the date & time (with UTC timezone) in ISO format. Example:

    <meta content="2023-09-21T10:47:04.440964+00:00" name="created">

I've updated the created timestamp to show hours and minutes with Z instead of +00:00. Example:

<meta content="2023-09-22T11:16Z" name="created">

@ajeanmahoney, Are you proposing to have two new meta tags with this request? i.e. publication date (derived from prepTime) and HTML created date.

Do we need to include time as well?

Note that the current prepTime includes time but not the timezone.

Yes, two new meta tags, which don't need HH:MM info:

• one that captures the prepTime of the XML file, for instance, with a label like the following (using the term 'publication' in the label would not be accurate because a file can be prepped for a while before it's published): <meta content="2023-08-01" name="XML-source-prepTime">
• one that captures when the HTML file was created: <meta content="2023-09-22" name="created">

If we have the time, why not include it?

Mainly it's an accuracy versus precision thing. There is a nonzero span of time between generating the document and making it publicly available. It's why RFCs currently show only the month and year in the doc header. In these meta tags, it doesn't matter as much, but if we were to show this information in the document itself, say in a colophon at the end of the doc, day resolution should be sufficient for the reader.