Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!ncar!gatech!bloom-beacon!eru!hagbard!sunic!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.text.sgml Subject: Re: What about the DTD Message-ID: Date: 19 Oct 90 17:28:48 GMT References: <8149@mcshh.hanse.de> <1990Oct5.003326.4284@cbnewsi.att.com> <1990Oct13.195117.26372@sq.sq.com> <1990Oct18.201850.9304@cbnewsi.att.com> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 57 Nntp-Posting-Host: hild.ifi.uio.no In-Reply-To: hrs1@cbnewsi.att.com's message of 18 Oct 90 20:18:50 GMT Originator: enag@hild In article <1990Oct18.201850.9304@cbnewsi.att.com> hrs1@cbnewsi.att.com (herman.r.silbiger) writes: I have heard much about the advantage of not having a standardized architecture, which will allow so much freedom in a publishing environment. However, I have never seen or heard of such an instance where the ODA architecture could not decscribe the structure of a document. If you know of such an example, please describe it. The system I designed for Oslo's financial daily's electronic news agency uses attributes to represent internal state information. We use marked sections to write different versions of an article, so that the journalist can chose which one to send when some political or economic decision has been made. We make extensive use of entities to represent ticker codes (also extremely useful for indexing). Interviews are represented like this: Question or interviewer comment Reply or other comment Reply or other comment Another question Another reply from NN ... etc. None of these can conveniently be described by ODA. Generally speaking, you can probably describe any document with both, but as far as I have looked into ODA, the granularity is not entirely of your own choice. The power of the ODA Generic layout model (I've forgot what ODA calls it), is not anywhere near the power of the SGML DTD. This is intentional in ODA. Too powerful tools makes for harder interoperability. (Thus a valid argument against SGML in general, but not the specific instances of its use.) I'm currently working on a project to represent a stock exchange ticker with sufficiently intelligent "markup" to be used for several kinds of display and processing purposes. An idea spawned off this project is representing EDI documents in a human readable form, and SGML seems to be up to the task. I don't even know if you could have EDI documents in an ODA environment. Anybody who cares to comment? Then there's the demands on the processing environment. An ODA environment needs to be pretty extensive to be useful, whereas an SGML environment could start with only a few hundred lines of Emacs lisp code. In most of the cases I've seen, interoperability with other systems is not that important, anyhow, which would make ODA overkill. Intelligent searching and indexing tools, however, has been much more important. It is easier to do this with SGML, and furthermore, the user can look at the SGML encoded document without an intelligent parser. This latter has had enormous importance with my clients. Your milage may vary, of course. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 --