From majordom@falch.no Tue Oct 10 01:34:28 1995 Return-Path: Received: from Norway.EU.net (nic.eunet.no) by utafll.uta.edu (4.1/25-eef) id AA24526; Tue, 10 Oct 95 01:34:24 CDT Received: from falch.no (falch.falch.no) by Norway.EU.net with SMTP id AA16429 (5.65c/IDA-1.4.4/EUnet/NO for ); Tue, 10 Oct 1995 05:31:13 +0100 Received: by falch.no (4.1/1.0) id AA29156; Tue, 10 Oct 95 05:31:00 +0100 Received: from novell.com (sjf-ums.sjf.novell.com) by falch.no (4.1/1.0) id AA29150; Tue, 10 Oct 95 05:30:48 +0100 Received: by sjf-ums; Mon Oct 9 21:48 PDT 1995 Received: by aristotle.sjf.novell.com.sjf.novell.com (5.0/SMI-SVR4) id AA04065; Mon, 9 Oct 1995 21:29:35 -0700 Date: Mon, 9 Oct 1995 21:29:35 -0700 From: jb@aristotle.sjf.novell.com Content-Type: text/plain Message-Id: <9510100429.AA04065@aristotle.sjf.novell.com.sjf.novell.com> To: dsssl-lite@falch.no Subject: Toward a specification of DSSSL Core Content-Length: 6805 Sender: owner-dsssl-lite@falch.no Precedence: bulk Status: R As the DSSSL Rapporteur Group of ISO/IEC JTC1/SC18/WG8 nears the end of its editorial work on ISO/IEC 10179, the question of DSSSL conformance levels comes to the fore. Almost a year ago, it became apparent to many people that we needed to define a minimum set of DSSSL features that would serve as a target for the first generation of DSSSL-compliant formatters. This minimum set, dubbed "DSSSL Lite", was informally specified in a draft by DSSSL architect James Clark in February 1995 and has been enabled in principle in ISO 10179 by making a number of DSSSL features optional and providing certain predefined functions in place of the full DSSSL query and expression languages. However, the exact boundaries of the desired initial implementation remain undefined. To help resolve this question, I have been asked by the DSSSL editors to prepare a set of documents that in conjunction with the standard itself will eventually serve as a specification for the first generation of DSSSL implementations. The outline that accompanies this message is the seed of one component of that specification, intended primarily to start a discussion that will elicit the input needed to decide the central question: Which DSSSL features are mandatory and which are optional? --------------------------- An overview of the approach --------------------------- We begin with the name. The members of the Rapporteur Group strongly prefer "DSSSL Core" over "DSSSL Lite" as the name of the mandatory subset of DSSSL, for two reasons. First, "Lite" is the well-known name of a particularly insipid brand of beer; and second, the term "DSSSL Lite" suggests incorrectly that what is being referred to is a standard parallel to and separate from DSSSL itself. This discussion is not about the establishment of a separate standard but rather about the definition of a conformance level of DSSSL. The approach taken in the outline that accompanies this message is based on several simple distinctions. The most important distinction is between the DSSSL Core and the rest of the standard. Core DSSSL consists of the core query language, the core expression language, and the core style language. Full DSSSL consists of core DSSSL plus everything else in the standard, including the transformation language, the full query language (SDQL), the full expression language, and the full style language. The core query language and the core expression language are now fully defined in ISO 10179; the focus here is on the definition of the core style language. Within the core style language, the distinction again is between those features and flow object classes that are mandatory and those that are optional. The task of defining the core style language might be seen as simply that of looking over each feature and flow object class in the full DSSSL style language and deciding which box to put it in. On examination, however, it becomes clear that a single set of mandatory features does not accurately reflect the real world of formatting tools. An analysis shows that existing formatting tools divide fairly naturally into two classes: the editors and browsers on one hand, and the typesetting systems on the other. SGML tools that fall into the first category include Author/Editor, InContext, Adept Editor, WordPerfect SGML, Explorer, Panorama, and DynaText; SGML tools that fall into the second category include Adept Publisher, FrameMaker SGML, CAPS, and DynaPage. While there are SGML systems that do not fall squarely into one set or the other, the distinction is fairly plain. Tools in the former category require a set of capabilities peculiar to dynamic online document display but need only rudimentary hardcopy formatting; tools in the latter category require extensive page formatting features but few or none of the online display capabilities. In light of this inherent distinction, the approach taken here is to define not one but two core style language sets. The first is called the DSSSL Core Online Style Language; the second is called the DSSSL Core Publishing Style Language. For convenience, these are referred to as dsssl-o and dsssl-p, respectively. (It is suggested that these names be lowercased except when they appear at the beginning of a sentence, in which case the first letter can be capitalized.) Dsssl-o and dsssl-p share a common set of style features and flow object classes, which is referred to here as the common core. This categorization strategy results in the following simple taxonomy for DSSSL style language features and flow object classes: * Mandatory style language features and flow object classes (core style language) - Common core - Dsssl-o = common core + features and flow object classes peculiar to editors and browsers - Dsssl-p = common core + features and flow object classes peculiar to high-level typesetting systems * Optional style language features and flow object classes ----------------- Initial documents ----------------- Two documents accompany this message to kick off the discussion of what constitutes DSSSL Core. 1. An outline of DSSSL features and flow object classes organized along the lines indicated above. This outline will be revised as the mail list discussion continues and will be placed on a suitable Web server as soon as it achieves a semblance of stability. 2. A collection of flow object synopses organized according to the categories in the outline and containing (a) a description of each flow object class, taken from a recent working edition of the Draft Standard, and (b) a list of the characteristics that can be applied to each flow object class. This is no substitute for the standard itself, of course, but it should prove helpful as a quick reference for participants in this discussion. A note about timing: I will be on vacation through October 15, and then I and the other members of the DSSSL RG will be occupied with editorial work on ISO 10179 during the week of October 16-20. Responses to input received on this proposed taxonomy may be slow in coming during this period. However, it was felt advisable to put this proposal before the DSSSL community without further delay. ======================================================================== Jon Bosak, Novell Corporate Publishing Services jb@novell.com 2180 Fortune Drive, San Jose, CA 95131 Fax: 408 577 5020 A sponsor of the Davenport Group (ftp://ftp.ora.com/pub/davenport/) ------------------------------------------------------------------------ The Library is a sphere whose consummate center is any hexagon, and whose circumference is inaccessible. -- Jorge Luis Borges (1941) ========================================================================