Newsgroups: comp.text.sgml Path: utzoo!sq!yuri From: yuri@sq.sq.com (Yuri Rubinsky) Subject: Re: What about the DTD Message-ID: <1990Oct13.195117.26372@sq.sq.com> Summary: SGML's requirement for a DTD is a strength (longish) Keywords: "SGML Document", DTD, architectures Organization: SoftQuad Inc., Toronto, Canada References: <8149@mcshh.hanse.de> <1990Oct5.003326.4284@cbnewsi.att.com> Date: Sat, 13 Oct 90 19:51:17 GMT Lines: 119 In article <8149@mcshh.hanse.de>, schiers@mcshh.hanse.de (Carsten Schiers) writes: > Hello, > > is the Document Type Definition (DTD) part of an SGML text interchange? .... > Is there something inside the SGML definition, which I don't have at > my desk, sorry, which tells me that a DTD is part of an SGML document? Clause 6 of ISO 8879 -- SGML deals with the structure of the entities which make up an SGML document and Clause 7 deals with the nature of elements within SGML. Together they explain that, for all practical purposes, an SGML document begins with an SGML declaration (which establishes the "default values" for a system, and which is optional), followed by a prolog (usually simply one DTD or a reference to it as Jim Howe points out in his article), followed by one or more "document instances", which follow the markup declared in the DTD. It is therefore the intention of SGML that interchange include, at the very least, a DTD (or reference to one) and an encoded text stream. _________________________________________________________________ However, Herman Silbiger (hsilbiger@attmail.com) writes: > SGML encoded documents cannot be used in an Open Interchange environment, > since, as you have found out, the document cannot be interpreted unless you > also have the DTD. This is one of the reasons that ODA adopted a standardized > architecture. > While it is true that ODA applications also must conform to a Document > Application Profile (DAP), these are hierarchical subsets of the complete > standard. If you conform to the highest level, you can understand all the > lower levels. In SGML, conforming to one DTD does not help you with the others. Conforming to SGML -- not (as Carsten has realised) to one DTD -- is the secret of success. SGML is a **language** which we use to build the architectures we need. This is precisely the strength of SGML. The odds are slim of all of us agreeing on architectures that will support us in our trade book publishing, our electronic disclosure of financial information, our creation of technical manuals for airplanes and aircraft carriers, our building of hypertexts in a variety of disciplines, our encoding of music, or poetry, or drama, our interchange of machine-readable dictionaries and research texts, our creation of training manuals and software reference guides. Indeed, the odds are very slim of our finding **one architecture** to support all this plus the things we can't yet imagine. But, with systems which can read any DTD, and "reconfigure" themselves to understand a variety of architectures, one is not restricted. _________________________________________________________________ jwh@boston.ifs.umich.edu (Jim Howe) is absolutely right in his description: > SGML is a language for defining DTD's. Since the DTD specifies the rules > used by your document it must be associated with your document in one > manner or another. This can be done either by including the DTD at the > start of your document or referring to the DTD through the use of the > PUBLIC identifier. If PUBLIC is used, the document processor must know > how to process documents that conform to the DTD specified by the PUBLIC > keyword. It could do this by knowing where to go to read the specified > DTD, or it could have the rules of the specified DTD built in. The last line of Jim's reply is particularly interesting. Clause 15 of the standard, which defines conformance, answers Carsten's other question: > To specify my question: does a software product, e.g. a publishing > system, which tells to be able to use SGML format, have to be able to > read an SGML document and *any* DTD? As I understand, then it has to > read the DTD, which is something like a grammmar for me, and then parse > the text, using this DTD. As Jim indicates, a software product may have a DTD built in which it supports. That product CANNOT claim to be a conforming SGML system: "A conforming SGML system shall be capable of processing any conforming SGML document ..." (where an SGML document may include any conforming DTD) but it may be a conforming **SGML application**. An application includes both formal (DTD, data content notations, etc) and often informal (application conventions, processing strategies) specifications for the handling of a particular class of documents. Generally "SGML application" has been treated as if synonymous with DTD, or as if it implies just one DTD, and that works most of the time. _________________________________________________________________ Carsten again: > I ask this, because a software manufacturer tells me, I have to send the > DTD for my special problem to him, and then he will return a special > filter for documents which behave like this DTD. So anytime I have a new > type of document, I have to buy a new filter. Your vendor is trying to cover for the fact that the software in question has an application built in, and is not a conforming **system**. You may have better luck by obtaining an SGML parser and translating your SGML input to the input required by the publishing system. _________________________________________________________________ Carsten also asks: > What is the idea of the CALS standard with SGML text exchange? CALS is a very broad defense industries initiative for the automation of acquisition and logistics databases. Among many other aspects, it specifies an SGML application strategy (an architecture for technical manuals and a direction for specifying architectures for other kinds of paper and paperless documents) as well as naming graphic standards for 2D, 3D and raster images. This is an enormous topic. My prediction is that it will one day have its own newsgroup. ---------------------------------------------------------------- Yuri Rubinsky (416) 963-8337 President (800) 387-2777 (from U.S. only) SoftQuad Inc. uucp: {uunet,utzoo}!sq!yuri 720 Spadina Ave. Internet: yuri@sq.com Toronto, Ontario, Canada M5S 2T9 Fax: (416) 963-9575