Versions of documents shall be identified by their year of publication and, optionally, their month of publication [...]
However:
the publication date is not directly related to the last time the document was modified/approved, and thus of limited semantic use to the reader and possibly out-of-sync with any internal date-based identifiers, e.g. URIs
the publication date is ambiguous when the document is published through multiple channels
the publication date does not provide any information not already provided by the approval date
Furthermore, the fact that the publication month is optional prevents automation and introduces inconsistencies when referencing documents. Instead versions of documents that are published should consistently be identified by the year and month of the approval date. This is similar to the approach used by the ITU:
AG 02, 10.1 currently states:
Versions of documents shall be identified by their year of publication and, optionally, their month of publication [...]
However:
the publication date is not directly related to the last time the document was modified/approved, and thus of limited semantic use to the reader and possibly out-of-sync with any internal date-based identifiers, e.g. URIs
the publication date is ambiguous when the document is published through multiple channels
the publication date does not provide any information not already provided by the approval date
Furthermore, the fact that the publication month is optional prevents automation and introduces inconsistencies when referencing documents. Instead versions of documents that are published should consistently be identified by the year and month of the approval date. This is similar to the approach used by the ITU: