Stricter requirements for document submissions (SD-7)
- Document number:
- P3702R0
- Date:
2025-05-19 - Audience:
- WG21
- Project:
- ISO/IEC 14882 Programming Languages — C++, ISO/IEC JTC1/SC22/WG21
- Reply-To:
- Jan Schultke <janschultke@gmail.com>
- GitHub Issue:
- wg21.link/P3702R0/github
- Source:
- github.com/Eisenwave/cpp-proposals/blob/master/src/sd-7-updates.cow
Contents
Introduction
Accessibility and legal concerns
Generative AI
Goals
Non-goals
Wording
References
1. Introduction
1.1. Accessibility and legal concerns
HTML is an extremely feature-rich file format. Among other features, this includes:
- Execution of JavaScript, which also includes manipulation of cookies and local storage.
- Responding to device properties via CSS media queries, like the operating system's dark/light theme preference.
-
Built-in interactive elements like
< input > < details > - Hyperlinks to within the same document and to other websites.
- Animated content, such as moving text.
- Embedded external website content, embedded videos, images, etc.
There exists an unwritten rule to keep HTML papers as simple and non-interactive as possible, but this has never been properly formalized.
1.2. Generative AI
ISO has recently published "Guidance on use of artificial intelligence (AI) for ISO committees" ([ISO-AI]). Among other principles, there is:
Respect ISO’s standards development policies
Do ensure you are familiar with, and abide by, the ISO Copyright policy and implementation guidelines, ISO/IEC Directives and ISO Privacy notice, which are mandatorily applicable to ISO technical work.Do not use images or text created by generative AI in any ISO content, either internally or externally.
While not all documents may be considered "ISO content", we expect them to be written by humans, not ChatGPT. This applies universally to meeting announcements, editor's reports, proposals, etc.
1.3. Goals
The purpose of this proposal is to come up with a set of rules that would:
- Ban the use of any legally problematic features, like cookies or local storage.
- Ban the use AI-generated content, in line with [ISO-AI].
- Require that some accessibility requirements are met.
- Limit the extent to which proposals can be interactive, especially in proposed wording.
-
Require that submitted documents are "self-contained".
That is, they should not become unreadable due to "link rot",
and internal references should actually be internal (
< a href = #id > - Modernize the document encoding requirements (UTF-8 everywhere).
- Generally clean up [SD-7] and make it more organized through the use of headings.
1.4. Non-goals
The goal is not to put a blanket-ban any technologies outside of "simple HTML" and CSS. There are many valid uses for more advanced parts. For example,
- The light/dark mode toggle in the top/right corner of this document makes use of a small amount of JavaScript. If you don't see the toggle, it's because you have disabled JavaScript. This is a simple, optional, visual enhancement.
-
Images can be used as visual aid in HTML proposals,
and if they are embedded directly within the document (e.g. as
< svg > -
External references to Google Fonts are often used to improve the appearance of the proposal
via custom fonts.
Relying on default browser fonts can make it difficult to provide a consistent reading experience;
note that Chrome on Windows uses Times New Roman as the default
serif font. Even if Google Fonts references were to die, the document would not become unreadable, just a bit uglier.
2. Wording
Change [SD-7] as follows:
| Doc. No.: | SD-7 |
|---|---|
| Date: | |
| Reply to: | Nevin Liber |
| Title: | Mailing procedures |
Note: This document is intended for WG21 committee members. If you are not a committee member, please see the How To Submit a Proposal page for public instructions about how to get started with a proposal.
This is a summary of the procedures to be used for submitting papers to PL22.16/WG21.
We are fortunate to have a very large volume of papers, but to allow everyone to make the best use of their time in reading the papers, some additional effort is needed from the authors.
- Please make sure the document header includes the information specified below.
- Non-trivial papers should include an abstract.
- Papers that revise earlier papers should provide a change history to allow people to focus on the changed sections of the paper.
Items (2) and (3) above are not needed for things like working drafts, papers that essentially just provide working paper changes for an issue or feature, and issue lists excerpts for reference by straw polls.
Document headers and metadata
The following information should be included in the document header:
Document NumberDocument Number: Nxxxx or PxxxxRyDateDate: yyyy-mm-ddReply-toReply-to: Name and email-addressAuthorsAuthors: (only if different than reply-to)-
AudienceAudience: working group(s) and/or study groups to which the paper is directed, or WG21 if the full committee
This may precede or follow the document title depending on the way in which your document is formatted.
In the past, many documents included something like:
“Project: ISO JTC1/SC22/WG21: Programming Language C++”
While you are welcome to include this, it is not necessary.
The above should only be considered as the information needed, not the formatting. People prepare documents in a variety of ways, and that is fine.
This was done to match the order in the bullet list above, and so that document numbers are explained first. Document numbers are arguably more important and commonly needed information than the audience.
Document numbers
Meeting announcements, minutes, working drafts, editor's reports,
and official document submissions (CD, PDTS, etc.),
and records of response must use N numbers.
; all other documents should use P numbers.
All other documents should use P numbers.
P documents will initially be published as P0xxxR0 PxxxxR0 (revision 0).
The document number in the paper header should be in that format.
If you submit an updated version at some point,
it will still be P0xxx Pxxxx, but will be revision 1.
The revision numbers only change when a document is submitted for a mailing.
The revision numbers only change when a document is submitted for a mailing.
Documents circulated as drafts should have D numbers
(Dxxxx for N documents, and D0xxxRn DxxxxRn for P documents).
Only documents for publication should have the N or P numbers.
To obtain a document number, send mail to vice-chair Nevin Liber. Include as much of the document header information as is available in the document number request.
Audience
In particular, the The “audience” is the piece of information
most commonly not made explicit.
For the audience, you can put working group names (Core, Evolution, Library, etc.),
study groups (concurrency Concurrency, modules Modules, etc.).
The group names are generally used in the document index,
so you might want to use those in your document.
But if you put SG1 in your document,
I will normalize that to Concurrency in the index.
I think we can simply delete it because the normalization is an implementation detail of the document index, and may be subject to change.
Note also that a document can have more than one audience.
File format and content requirements
Documents must be in PDF (.pdf), HTML (.html or .htm), text (.txt), or Markdown (.md) format.
For Markdown files, use UTF-8 encoding.
All documents should use UTF-8 encoding.
For HTML files, make sure that the encoding is specified in the file.
For text files, please use US ASCII (ISO 646) encoding.
Otherwise, UTF-8 HTML papers papers without
General rules
- Documents shall not contain content that is illegal, plagiarized, and/or produced by generative AI.
-
Documents should be accessible.
For instance:
- Text should be high-contrast.
-
Any non-decorative image should include an alt text
(
![...]() in Markdown,<img alt=...> in HTML, etc.). Alternatively, the contents of the image should be described in text. -
In HTML documents, you can use
<math> (MathML) tags for math formulas; assistive technology like screen readers can process these.
-
Except for plain text files,
code samples should use monospace/code font.
This can be done with
``` in Markdown,<pre> in HTML, etc.
The goal here is to establish a minimum set of rules that every document needs to satisfy. For example, yellow-on-white Times New Roman code blocks could be considered such a severe violation of the mailing procedures, that the author could be required to revise the paper.
Furthermore, while we cannot expect all submitted documents to have AAA compliance with the [WCAG], the [ISO-Coc] requires us to "Promote and enable all voices to be heard", and raising awareness for document accessibility is a good step towards that.
Rules for HTML documents
-
Documents shall not use any technology that requires user consent in some countries.
This includes
<embed> s with third-party content, cookies, etc. -
All non-decorative content should be static and readable with JavaScript disabled.
For example, do not hide possible design or wording options for a proposal in a
<detail> element. However, you can use JavaScript and other interactive features for dark/light theme toggles, to show/hide sidebars, and other optional enhancements. - Documents should only use features that are commonly supported by modern browsers.
-
Documents should be portable.
That is, when the HTML file is downloaded and viewed offline with
file: protocol, all non-decorative content needs to be readable. In particular, images and other media need to be embedded in the HTML file, not loaded from an external website. You can use external sources for fonts, as long as the document is readable without these fonts (in an uglier state).
Rules for Markdown documents
Markdown documents should follow the following rules:
- Files should be usable either in their original text form or as formatted by a Markdown processor, so make sure the text form is well formatted.
- The document should follow the Commonmark specification.
Submission deadlines
The pre-meeting mailing deadline is the Monday four weeks before the start of the meeting.
The post-meeting mailing is the Monday three weeks after the start of the meeting.
All papers must be received by the vice-chair by 15:00 UTC on the Monday of the mailing deadline.