Amendments and corrigendums parsing and creation

mico commented 1 year ago

I found the way I treat corrigendums and amendments for IEEE is different. The data I used to create the parser and constructor looks like:

IEEE Std 1003.1-2001/Cor 2-2004
IEEE P1722-2016-Cor1/D0, June 2016
IEEE/ISO/IEC 8802-3:2021/Amd8-2021
ISO/IEEE 11073-20601:2010/Amd 1:2015(E) (Adoption of IEEE Std 11073-20601a-2010)

So, you can see Amendments only applied to ISO format identifiers, but corrigendums only goes with IEEE format.

Because of that, the way I parse and create identifier makes it not possible to parse something like:

IEEE Std 1003.1-2001/Amd 2-2004

And create amendment to identifier like this without using pubid-iso (output will be in ISO format in this case).

I think it's not correct. By exploring identifiers on ieee.org I found there are amendments in IEEE format:

IEEE/ISO/IEC 8802-1Q-2020/Amd31-2021

Update: the example above is parsable as ISO format, so the parser still works with that. I still didn't manage to find amendment in IEEE format only.

and corrigendum in ISO format:

ISO/IEC/IEEE 8802-3:2017/Cor.1:2018(E)

Also, there are amendments and corrigendums without number and version, like this:

IEEE P802.3bk/D3.0, March 2013 (Amendment of IEEE Std 802.3-2012)

I believe it could be something like IEEE P802.3bk/Amd1/D3.0, March 2013 (are we using draft's year for amendment?) We need to decide what will be output for identifiers like this. Do we keep mentioning amendment in brackets only when it's first amendment, or we should include amendment in identifier's part? (IEEE P802.3bk/D3.0, March 2013 (Amendment of IEEE Std 802.3-2012) vs IEEE P802.3bk/Amd1/D3.0, March 2013). But for this case seems original identifier changed from IEEE Std 802.3-2012 to IEEE P802.3bk. Why did we get "P" as prefix and "bk" as suffix?

Some more examples for better picture:

IEEE Std 802.1BA-2011/Cor 1-2016 (Corrigendum to IEEE Std 802.1BA-2011)
IEEE P802.1AE-2018-Rev/Cor1/D1.0, August 2019 (Corrigendum to IEEE Std 802.1AE-2018)

IEEE Std 802.3by-2016 (Amendment to IEEE Std 802.3-2015 as amended by IEEE Std 802.3bw-2015)

Is "by" and "bw" something related to amendment version? 🤔

mico commented 1 year ago

P802.1ah/D4.0, Nov 2007 - IEEE Draft Standard for Local and Metropolitan Area Networks--Virtual Bridged Local Area Networks--Amendment 6: Provider Backbone Bridges (IEEE Draft Amendment to IEEE Std 802.1Q -REV)

This is not parsable. Should I parse identifiers like this as well?

mico commented 1 year ago

@ronaldtse the question is what to do with amendment/corrigendum description in brackets ((Corrigendum to IEEE Std 802.1BA-2011), (Amendment to IEEE Std 802.11-2012, as amended by IEEE Std 802.11ae-2012, IEEE Std 802.11aa-2012, IEEE Std 802.11ad-2012, and IEEE Std 802.11ac-2013)). If we decide to convert something like IEEE P802.3bk/D3.0, March 2013 (Amendment of IEEE Std 802.3-2012) to IEEE P802.3bk/Amd1/D3.0, March 2013 it is not clear what we do with something like IEEE Std 802.11af-2013 (Amendment to IEEE Std 802.11-2012, as amended by IEEE Std 802.11ae-2012, IEEE Std 802.11aa-2012, IEEE Std 802.11ad-2012, and IEEE Std 802.11ac-2013).

By counting identifiers after "as amended by" we can say it's amendment number 5, so it could be something like IEEE Std 802.11af-2013/Amd5 but maybe we want to keep previous amendments, so output could be IEEE Std 802.11af-2013/Amd5 (Amendment to IEEE Std 802.11-2012, as amended by IEEE Std 802.11ae-2012, IEEE Std 802.11aa-2012, IEEE Std 802.11ad-2012, and IEEE Std 802.11ac-2013), but it still questionable, because "af" suffix only points to this amendment, so I'm not sure if we need to add "/Amd5"...

The question comes from the way I parse and create identifiers now: corrigendum's parameters for something like "/Cor 1:1999" provided through parameter "corrigendum", but corrigendums in the brackets provided through parameter "corrigendum_comment". Now when I see bigger picture I don't think it's correct and I feel we should apply everything through one parameter, and we should decide on output format.

mico commented 1 year ago

Another discovery: https://github.com/metanorma/pubid-ieee/blob/e8fec5120b9e3289fa9e23ebf9fc511d948e1fad/spec/pubid_ieee/identifier_spec.rb#L535-L536 So, I already convert identifiers with "Corrigendum to" in brackets to corrigendum as suffix, but I don't do this for amendments.

ronaldtse commented 1 year ago

To get to the bottom of the issue, I found some IDs from standards.ieee.org:

Corrigendum

IEEE 802.1AS-2020/Cor 1-2021
P1671.1-2017/Cor 1
IEEE P1609.2.1-2022/Cor 1
IEEE 1722.1-2013/Cor 1-2018
IEEE P516-2021/Cor 1.1
IEEE C37.016-2018/Cor 1-2021
IEEE C37.09-1999/Cor 1-2007
IEEE 1900.6-2011/Cor 1-2015
IEEE C95.1-2019/Cor 2-2020

Amendments

ID	Title
IEEE 1588b-2022	IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Amendment 1: Precision Time Protocol (PTP) Mapping for Transport over the Optical Transport Network (OTN)
IEEE 1588g-2022	("g" stands for IEEE Approved Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Amendment: Master-slave optional alternative terminology
IEEE 802.11ax-2021	IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks--Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 1: Enhancements for High-Efficiency WLAN
IEEE 1680.1a-2020	IEEE Standard for Environmental and Social Responsibility Assessment of Computers and Displays--Amendment 1: Editorial and Technical Corrections and Clarifications
IEEE 802.1ABcu-2021	IEEE Standard for Local and metropolitan networks--Station and Media Access Control Connectivity Discovery Amendment 1: YANG Data Model
IEEE 802.3dd-2022	IEEE Standard for Ethernet Amendment 1: Power over Data Lines of Single Pair Ethernet