ABPSC 3.4b1 NO IDEA Avatar
  1. OMG Issue

ABPSC — Revise Revision Report Generator to Satisfy Community Needs

  • Key: ABPSC-65
  • Status: open  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    The recently revised Revision Report Administration Page provides a number of good improvements, but it is still very unintuitive, and compared to the previous version, fails to satisfy the community and process needs.

    Clear and understandable input fields are required for the following information. Each input filed must have a clear and specific title, leaving no question about purpose and format:

    (1) Specification Information:
    (1a) Exact Specification Title
    (1b) Specification Version [ no "Alpha", "Beta", etc ]
    (1c) Specification Acronym
    (1d) Specification Version Stamp

    Document Information Note, there may be multi-volume specifications. The input format must support that.

    (2) Specification Document Input (for each specification volume):
    (2a) Exact name of the Specification Volume [ with implied document number assignment ]

    Alternatively, input of a multi-volume specification as ZIP archive shall be supported:

    (2b) ZIP Archive Name [ with implied document number assignment ]
    (2c) File Name and Exact Volume Title for each specification volume [ repeated ]

    Note, in a multi-document specification, not every document may have changed during the revision process, therefore it would be very helpful for the specification reviewer if the changed documents could be flagged.

    The exact same facilities as under (2) must be provided for change marked specification volumes.

    The creation of ancillary attachment files / archives for the purpose of the revision report shall be transparent and invisible to the user

    Machine Consumable Files:

    All Machine Consumable Files MUST have a Version Stamp URL. This is necessary for version management, until the OMG adopts a professional version management scheme, like GIT, etc. For files that require a different (additional) URL, an optional URL filed shall be provided by the input facility. Single File Input and ZIP Archive Input shall be supported. The below described Input Facility shall be provided two times with identical layout. Once for NORMATIVE files, and once for INFORMATIVE files.

    (3) Machine Consumable Files Input
    (3a) File Name [ with implied document number allocation ]
    (3b) File Description
    (3c) Alternative URL [ optional ]
    (3d) Version Stamp Override [ optional - accommodating reuse of files from previous versions ]

    For Multi-File Input as ZIP Archive:
    (3e) ZIP Archive Name [ with implied document number allocation ]
    Then repeated input (3a) to (3d) for each file in the ZIP Archive.

    As stated, this input facility must exist twice with identical layout, for NORMATIVE and INFORMATIVE Machine Consumable Files.

    Specification Maintenance Support.
    To facilitate specification maintenance, a specification maintenance archive is required. It is currently called "Ancillary" but shall be called "Maintenance" to avoid confusion with the ancillary attachments of the report.

    The Maintenance Archive shall have a private URL with the SAME Acronym and Version Stamp as the corresponding Normative Machine Consumable Files of the Specification to allow unambiguous association.

    Only the Maintenance Archive file name [ with implied document number allocation ] is needed as input field.

    However, the Maintenance Archive must contain at least:
    (4a) SVG files for all images
    (4b) Editable Model sources - if models are used in specification
    (4c) Document sources - if needed for reproduction
    (4e) Other necessary items

  • Reported: ABPSC 3.3 — Fri, 23 Feb 2024 00:15 GMT
  • Updated: Fri, 23 Feb 2024 00:15 GMT