ISO/IEC JTC1/SC18/WG8 N1605 Title: Interim Report on the SGML Review Source: SGML SWG Project: 1.18.15.1 Project editor: C. F. Goldfarb Status of document: WG8 Approved report Requested action: For information Date: 7 May 1993 Distribution: WG8 and liaisons ISO 8879 (SGML) was published in October 1986, and in 1991 was subject to the formal 5-year review ballot required of all ISO standards. The ballot reaffirmed ISO 8879 (source: SC18 N3128). With this support, WG8 directed the Project Editor to conduct a systematic review of the standard to consider future development. WG8 has agreed to a set of principles for any future development, a copy of which is attached (JTC1/SC18/WG8 N1289). These principles ensure that all existing conforming SGML documents will continue to conform after any changes are made to the standard. WG8 has also adopted a policy for the review, a copy of which is also attached (JTC1/SC18/WG8 N1350). The review process ensures that every clause, paragraph, note, and syntax production of ISO 8879 is reviewed. The review is structured in two independent threads: 1. Defining explicitly the information described by the SGML syntax and grouping it, as appropriate, into useful "information sets", such as the Element Structure Information Set (ESIS) (see WG8 N1035). 2. Accumulating comments and proposals for specific aspects of SGML. Once the first thread is completed, we will conduct a clause-by-clause examination of the standard to insure completeness of the second thread. We will then formulate and publish our recommendations for change and proceed to develop appropriate text for balloting. Upon approval, the changes will be incorporated into the text of ISO 8879, together with Amendment 1, and the integrated text will be published. The review has progressed sufficiently that we can state that changes will be recommended. In order to acquaint the SGML community with the types of change we are contemplating, we have prepared an initial list of requirements and associated changes. Please note that the list is by no means complete with respect either to the set of requirements or the possible changes associated with each requirement. Nor do we believe it to be statistically representative of the changes that we will eventually recommend. The list follows, in no particular order: Requirement: To facilitate automatic translation of well-defined document character sets with human inspectability of the translation information (Note: This information is not required for SGML parsing.): 1. Add the ability to specify when the definition of a character set is represented using the format of the character set description parameter of the SGML declaration. 2. Add the ability, within a character set description, to identify a base set character by its string name (not just by its character number). 3. Add the ability to indicate when the string name for a base set character is taken from the ISO10646 character registry, rather than being the name used in the base set definition itself. (For ISO sets, the two are normally the same.) 4. Allow the base set of a formal character set definition to be itself a formal character set definition. This allows subsets of large character sets to be used in the definition of other character sets. Requirement: To facilitate automatic generation of display character entity sets from definitional character entity sets. 1. For definitional character entity sets, add the ability to define the entity text as either a character in a defined character set and/or by an ISO10646 character registry name. Requirement: To facilitate more powerful management of sophisticated versioning requirements. 1. Allow Boolean combinations of INCLUDE and IGNORE keywords in marked section declarations. Requirement: To enhance the usefulness of capacities. 1. Make specification of any or all capacity limits in a document optional. 2. Make an SGML system's support for any or all capacity limits optional. 3. Add capacity limits for document instances, such as number of elements, number of data characters, etc. 4. Allow optional specification of actual capacities (not just capacity limits). Requirement: To provide more flexibility for attribute design. 1. Allow a given name token to appear in the declared value of more than one attribute in the same attribute definition list. 2. Allow multiple attribute definition list declarations for a single element type. Requirement: To simplify the specification of SGML declarations. 1. Allow reference to an existing SGML declaration with local modifications. Requirement: To allow more choices among optional SGML features. 1. Modularize the SHORTTAG feature so that attribute minimization can be used with or without allowing empty tags. Requirement: To clarify difficult portions of the text of the standard. 1. Clarify the description of record boundary handling, explaining clearly the relationship between detecting data characters and ignoring characters, including whether ignored characters are first recognized as data characters. ATTACHMENT 1 of 2  ISO/IEC JTC1/SC18/WG8 N1289 Title: Future development of ISO 8879 Source: WG8 Project: 1.18.15.1 Project editor: C. F. Goldfarb Status of document: Agreed WG8 Position Requested action: For information Date: 7 May 1990 Distribution: WG8 and liaisons The future development of ISO 8879 shall be consistent with the following principles: 1. Any document that is a conforming SGML document according to the current standard shall continue to be a conforming document under the provisions of future versions of the standard. 2. The results of parsing an SGML document (that is, the element structure information set, or "ESIS") that conforms to the current standard shall be unchanged when the document is parsed under the provisions of future versions of the standard. 3. A document that is classified as a minimal or basic conforming SGML document under the current standard shall continue to be classified as such under the provisions of future versions of the standard. NOTE 1 -- These principles should not be construed to mean that no changes can be made to ISO 8879. To meet evolving user requirements, for example, some changes of the following types are possible without violating the above principles: a) Relaxing restrictions b) Adding new constructs c) Partitioning existing optional features d) Introducing options to allow the suppression of troublesome existing constructs, when experience indicates that the constructs tend to induce user errors with serious consequences 4. Future versions of the standard shall require conforming SGML parsers and systems to support conforming SGML documents, minimal conforming SGML documents, and basic conforming SGML documents to at least the same extent as the current standard. NOTE 2 -- Future versions of this standard can introduce additional requirements as well. NOTE 3 -- These principles should not be construed to mean that the definition of a "conforming SGML document" cannot be changed, only that existing conforming SGML documents will continue to be classified as such. ATTACHMENT 2 of 2 ISO/IEC JTC1/SC18/WG8 N1350 Title: Policy for the Review of ISO 8879 Source: WG8 Project: 1.18.15.1 Project editor: C. F. Goldfarb Status of document: Agreed WG8 position Requested action: For information Date: 11 Oct 1991 Distribution: WG8 and liaisons WG8 has directed the Project Editor of ISO 8879 to conduct a detailed review of the standard to consider future development. The review process will ensure that every clause, paragraph, note, and syntax production of ISO 8879 is reviewed. The review is not expected to result in any substantive change to the scope of ISO 8879. All proposed changes will adhere to the principles expressed in WG8 N1289, "Future development of ISO 8879." NOTE -- WG8 N1289 mandates upward compatibility such that conforming SGML documents and applications will remain conforming regardless of changes to ISO 8879. However, it does not necessarily protect existing conforming systems: SGML parsers, for example, may need to be modified to recognize new constructs (that is, to recognize documents that do not conform to the current standard but may conform to a future version). Nor does N1289 protect nonconforming documents: text that is currently erroneous might be considered valid by a future version of ISO 8879. If the review results in function being added to a future version of ISO 8879, there shall be a revised SGML declaration that will allow identification of the ISO 8879 version to which a document conforms. A document conforming to the 1986 version (with a 1986 SGML declaration) shall continue to conform in any future system, and to be interpreted in exactly the same way. NOTE -- This rule applies to all of SGML, including the element structure, entity structure, and nesting of marked sections. It shall be possible to create an equivalent future SGML declaration for every 1986 SGML declaration. The prolog and document instance set of a 1986 conforming SGML document will be interpreted identically by any future SGML system with either of the equivalent SGML declarations. As SGML end users and their managers can now learn about SGML in a less formal way than by studying the standard, any proposed changes to the standard resulting from the review process will be written for an audience consisting primarily of software developers, software testers, and members of standards committees. The review process will be a single-stage process. Any future development of the standard will be done in a coherent manner, not piecemeal. The complete design from the top down will be understood before development of details is prioritized. Technical work and possible reorganization will be completed before final wording of individual paragraphs is attempted. If experts disagree for good reason over the interpretation of some provision of the standard, the provision shall be considered ambiguous and resolution of the ambiguity shall be considered a corrigendum, rather than added function. To protect users and implementers from having to make multiple revisions to remain current with the standard, intermediate publication of corrigenda will be considered only in the unlikely event that serious problems with the current version are encountered. However, any changes in a revised version of ISO 8879 that are in fact corrigenda will be identified as such, as they could affect the determination of whether upward compatibility has been maintained. The user requirements for SGML as presented by each participating expert will be given equal respect, even if other experts have not encountered some requirements in their own work. SGML must accommodate all the requirements. It is expected that not all SWG meetings will be equally well attended. Complete records will be kept of meetings to keep absent members informed, and to assure consistency of direction from meeting to meeting. In particular, major issues that were resolved at a large meeting will not be reopened at a subsequent smaller meeting in which advocates of one side or the other are not present.