From 1e5b8c7badfa654199f8bbb5d4aa12ea108cb96b Mon Sep 17 00:00:00 2001 From: Steve LLamb <38917682+SteveLLamb@users.noreply.github.com> Date: Tue, 25 Feb 2025 14:55:25 -0800 Subject: [PATCH 1/8] pass update for HTML --- doc/main.html | 74 ++++++++++++++++++++++++++++----------------------- tooling | 2 +- 2 files changed, 42 insertions(+), 34 deletions(-) diff --git a/doc/main.html b/doc/main.html index b7529a4..4f1f5dc 100644 --- a/doc/main.html +++ b/doc/main.html @@ -35,12 +35,15 @@
All new Engineering Documents shall use .
+All new Engineering Documents shall use .
Prior to being submitted for pre-FCD ballot review, draft Engineering Documents may use other editing formats, as selected by the Project Group.
- An Engineering Document may be revised in its existing format, with the - explicit permission of the Standards Vice President or Director of - Engineering. -
-- For a revision of an Engineering Document, the Project Group should start with the Publication Master, which usually can be obtained from SMPTE HQ. The Project Group may, at its discretion, recreate the original document, as published, if an editable master cannot be found. The Project Group is encouraged to follow the but is under no obligation to do so. + For a revision of an Engineering Document, the Project Group should start with the Publication Master, which should be HTML format. If not already published in HTML, the Publication Master can usually can be obtained from SMPTE HQ. If this is the case, the Project Group should recreate the original document, as closely as possible to published, in HTML format as per , prior to any revision work to be done. This will ensure the tooling can create a proper redline document during the balloting process. If this cannot be done, the document may be created as a "new" document as per the HTML guidelines, but this will not create redlines in the tooling.
+Care should be given when updating the tooling from prior HTML published versions, as major changes in said tooling may have occured. However, such changes may be required, such as general boiler plate verbiage, template update, and/or validation tools.
+Since the HTML pipeline has been introduced, amendments are no longer able to be generated, only full revisions. As such, amendments shall no longer be utilized.
+With the exception of figures, the main element shall be submitted as a single HTML document, as specified at .
+With the exception of figures, the main element shall be submitted as a single HTML document, as specified at .
Images referenced in the main element shall use one of the following formats:
@@ -387,7 +388,7 @@- Various document packages are needed during the development process. In all cases, a document being reviewed or voted upon shall be the current draft which is the “clean” version. + Various document packages are needed during the development process. In all cases, a document being reviewed or voted upon shall be the current draft which is the “clean” version, generated in zip file within the GitHub release as described in . All the below described packages are auto-generated by this tooling and shall not be created by hand.
In the event that any of the following is in conflict with the , the shall prevail. @@ -397,7 +398,7 @@
- of this AG has guidance for the use of templates for new projects, Revisions and Amendments. + of this AG has guidance for the use of templates for new projects and Revisions.
For Revisions the process of converting an old document into the current template changes section numbering and alters the appearance of the original document, even though the content of the document has not changed. In this case, it is recommended that the conversion to the current template should be made before any other changes are made. The document editor should “accept all changes” to create a clean starting point (the “baseline draft”) from which to track the technical and/or editorial revisions to the document. @@ -425,9 +426,6 @@
+ A Comment Resolution Record is required when there are additional FCD Ballot(s). This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance. +
++ A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance. +
When Comment Resolution has been successfully completed, a Pre-DP Review follows. Comment resolution may include one or more Disposition Votes. See for guidance.
@@ -523,10 +525,11 @@+ A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance. +
+ A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance. +
After a successful DP vote the Draft Publication Vote Package documents shall not be edited by the Project Group participants or the Technology Committee Chair(s) with the exception of changing the document status. If new editorial issues are found, these should be documented and given to SMPTE HQ (see ).
@@ -568,10 +572,11 @@+ A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. If the Project Group kept other records, these must be included. See for guidance. +
manifest.json
file as defined in .
+ All new Engineering Documents shall use .
+All Engineering Documents shall use and .
Prior to being submitted for pre-FCD ballot review, draft Engineering Documents may use other editing formats, as selected by the Project Group.
-- For a revision of an Engineering Document, the Project Group should start with the Publication Master, which should be HTML format. If not already published in HTML, the Publication Master can usually can be obtained from SMPTE HQ. If this is the case, the Project Group should recreate the original document, as closely as possible to published, in HTML format as per , prior to any revision work to be done. This will ensure the tooling can create a proper redline document during the balloting process. If this cannot be done, the document may be created as a "new" document as per the HTML guidelines, but this will not create redlines in the tooling. + For a revision of an Engineering Document, if not already published in HTML, the Publication Master can usually can be obtained from SMPTE HQ. The Project Group should recreate the original document, as closely as possible to published, in HTML format as per , prior to any revision work to be done. This will ensure the tooling can create a proper redline document during the balloting process.
Care should be given when updating the tooling from prior HTML published versions, as major changes in said tooling may have occured. However, such changes may be required, such as general boiler plate verbiage, template update, and/or validation tools.
Since the HTML pipeline has been introduced, amendments are no longer able to be generated, only full revisions. As such, amendments shall no longer be utilized.
@@ -112,7 +110,7 @@- SMPTE Engineering Documents may be published on paper or in various electronic formats and may comprise one or more separate elements. An Engineering Document always shall include a single prose element and may include other elements such as XML, spreadsheets, media files, and so forth. The collection of elements, regardless of formats employed, is the "Engineering Document" as a whole, and all elements shall be clearly identified in the prose element (see ). Any change to any element constitutes a change to the Engineering Document. The Project Group and the Technology Committee shall determine the number of elements for publication. The Director of Engineering shall determine the distribution media for all published documents. The format of publication shall alter neither the relevance of, nor the processes that otherwise are required for approval of, an Engineering Document. + SMPTE Engineering Documents shall be published in HTML and may comprise one or more separate elements. An Engineering Document always shall include a single prose element and may include other elements such as XML, spreadsheets, media files, and so forth. The collection of elements, regardless of formats employed, is the "Engineering Document" as a whole, and all elements shall be clearly identified in the prose element (see ). Any change to any element constitutes a change to the Engineering Document. The Project Group and the Technology Committee shall determine the number of elements for publication. The Director of Engineering shall determine the distribution media for all published documents. The format of publication shall alter neither the relevance of, nor the processes that otherwise are required for approval of, an Engineering Document.
Engineering Document Elements may be packaged as one or more Elements using ZIP to facilitate the organization and distribution of the component files. From e740ee5907d48d70ae512aca47ca3b5c29ed0db4 Mon Sep 17 00:00:00 2001 From: Steve LLamb <38917682+SteveLLamb@users.noreply.github.com> Date: Tue, 25 Feb 2025 15:20:41 -0800 Subject: [PATCH 3/8] updates per feedback --- doc/main.html | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/main.html b/doc/main.html index 7229ae4..b2eba92 100644 --- a/doc/main.html +++ b/doc/main.html @@ -39,6 +39,8 @@ https://doc.smpte-doc.org/ag-03/main/