PWG Policy for Maintenance and Approval of Schemata - March 16, 2016 ------------------------------------------------------------------------- Status: Approved Editor: William A Wagner (wamwagner@outlook.com) Abstract This policy document extends PWG Standards Development and Maintenance and the Formal PWG Standards-Track Process defined in the PWG Standards Development Process V 3.0 document (sections 3 and 4) to Schemata, structured frameworks or plans using documenting techniques such as diagrams on non-natural coding languages such as XML rather than standard English text. This version is available in the directory: http://ftp.pwg.org/pub/pwg/general/process/schemata-policy-20160506.txt References: 1. The Printer Working Group Definition of the Standards Development Process Version 3.0: http://ftp.pwg.org/pub/pwg/general/pwg-process-30.pdf, January 1, 2009 ------------------------------------------------------------------------- PWG Policy for Maintenance and Approval of Schemata (Normative) 1 INTRODUCTION Section 3 and 4 of the PWG Definition of the Standards Development Process v3.0, (Standard Process Document) define the processes for development, formal approval and maintenance of PWG documents including specifications and standards. However, these processes assume an English language document which can be readily edited and reviewed. In some cases, a more concise and ultimately clearer specification can be provided using diagrams or coding languages. This is particularly applicable to the Semantic Model documentation. However, PWG member representatives contributing to or reviewing to the content of such documents and those considering the approval of such documents may not be proficient in the languages or documentation techniques used. There typically are capabilities for representing the content of such documents in graphical form, or in other ways comprehensible to those not proficient in the particular language used. This document describes how the workgroup is to effect and the PWG is to support the development, formal approval and maintenance of Working Drafts, Candidate Standards and Standards, as defined in the Standard Process Document, that are generated as Schemata. 2 ENSURING COMPREHENSIBILITY 2.1 CHARTER PHASE The principle documents to be generated by a workgroup are identified in the workgroup charter, which generally is subject to formal approval by the PWG membership. If the workgroup determines that a definitive project document is to be represented in schema form, the specific method to be used for documenting and for providing generally reviewable versions of the document for those contributing to, evaluating and/or voting on the document must be stated in the charter. Approval of the charter indicates that the PWG membership agrees to the additional effort and potentially cost to the PWG of supporting the identified form of documentation. 2.2 DEVELOPMENT PHASE The Formal PWG Standards-track Process for schemata is to follow the process described in section 4 of the Standard Process Document with the additional provisions described below. It is important that, during the development phase, members of the workgroup as well as others interested in the development can understand, comment on and contribute to the document. To do this, both the definitive form of the document and representations of the document content that do not require special tools or schema knowledge must be made available. A repository is to be created on GitHub to store, make accessible and track working versions of the schema code. The code in this repository is to represent the current working version of the document as well as at least the last version that reflects the results of a complete review by the workgroup. The workgroup chair is to assign a person or persons responsibility for having the code reflect changes agreed to by the workgroup. The responsible person(s) will be provided with necessary tools (possibly provided by the PWG) and access to the code; alternatively or in addition, the responsible person(s) will be provided with professional help, funded by the PWG. to update and maintain the schema and to provide reviewable versions to the workgroup in a form identified when the project was added to the workgroup charter. To allow review, representations of the document content that do not require special tools or schema knowledge (for example, browseable graphic versions of XML schema) of the working level code are to be made accessible on GitHub from the workgroup ís PWG Web page. These versions are to be updated: a. Whenever there is a new workgroup-approved major or minor update. b. Just prior to a PWG Face-to-face meeting, if there have been any changes since the last PWG Face-to-face meeting of the workgroup. c. When the consensus of active members of the workgroup calls for an update to allow proper consideration of proposed changes. d. When there is an intended release of the document that requires PWG formal approval, to allow for PWG Last Call, and again to reflect any changes as a result of Last Call Comment Resolution prior to PWG Vote. 2.3 FORMAL VOTE AND MAINTENANCE PHASE This process provides for the PWG formal approval of definitive PWG standards documented as schemata rather than English text, without the need for an accompanying English text specification. Formal approval of such documents follows the Approval process described in Section 8 of the Standard Process Document, with the additional provisions described below. As specified above, the submitting workgroup is to provide updated representations of the document content that do not require special tools or schema knowledge whenever there is a release of the document that requires PWG formal approval, to allow for PWG Last Call, and again to reflect any changes as a result of Last Call Comment Resolution prior to PWG Vote. Major Releases to a schema are subject to formal approval by the PWG membership, as described in Section 8 of the Standard Process Document. Approval of Minor Updates is regarded as a maintenance action, and requires a Call for Objections process, as described in Section 9 of the Standard Process Document. 2.3.1 Major Releases A Major Release is considered to be: a. Release of a new version that the workgroup determines requires a new first level version number change (e.g., version 3.0 updating version 2.8). b. A release that could make implementations derived from the previous version incompatible with the proposed version. 2.3.2 Minor Releases A Minor Release does not have the potential to make any implementation derived from the previous version incompatible with the proposed version. Minor changes can be grouped for PWG Approval, but any minor change agreed to by the workgroup must not go longer than a year without being put up for PWG Approval. A Minor Release is considered to be: a. Release of a version that the workgroup determines requires a new second-level version number change (e.g., version 2.9 updating version 2.8) b. Release of a version that includes one or more minor changes such as changes or additions to allowable element values.