Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!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: 23 Oct 90 04:15:01 GMT References: Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 103 Nntp-Posting-Host: hild.ifi.uio.no In-Reply-To: mss+@andrew.cmu.edu's message of 21 Oct 90 19:35:15 GMT Originator: enag@hild I've reviewed the articles I wrote under this subject, and I'm having a hard time matching Mark Sherman's comments to mine. Quoting from the original article may be wasteful of bandwidth, but it ensures that the reader can check the reply against the question. I wrote: "... as far as I have looked into ODA, the granularity is not entirely of your own choice." Mark replies: There is no substantive difference between the granularity of ODA's specific logical structures and SGML's tagged documents. Both are essententially trees: nodes, edges and leaves. Both allow and neither one requires that, say, a chapter or a word be a piece of the structure. What else is there to say? Apart from my stressing _choice_, I have already mentioned several powerful elements having no ODA counterpart. I wrote: "The power of the ODA generic [logical structure], is not anywhere near the power of the SGML DTD." Mark replies: There are some differences between ODA's generic logical structure and SGML's DTD, but both have more complexity than most documents use. I said "SGML > ODA"; you counter with "There exists an X such that SGML > X and ODA > X". You can convert ODA to SGML and back without loss of information, but you can't do it the other way around without loss of information. To me, this is sufficient to support my "SGML > ODA" claim. I wrote: "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." Mark replies: Before you say how easy it is to search SGML text, are you expecting all of the tags to be explicit (or expecting all of them to be implicit)? Depending on the application, the lack of tags makes searching useless (while in other applications their presence gets in the way). What about multiple revisions? Just searching for a string doesn't tell you if it is really in the document -- you've got to parse the structure to see when it applies. I intended to imply by the use of the term "intelligent searching and indexing tools" that they should take the structure of the document into consideration. I do not regard anything which does not know the structure of an SGML document to be intelligent. Ergo: Parse the document or die. Additionally, you may use existing tools while the new, improved ones are being built. Hmmm, I really thought I wrote something on a prototype, but I can't find it. My, how I miss intelligent searching and indexing tools! :-) I wrote, at least: "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." Mark replies: I can "cheat" in ODA as well as SGML, and say that I'll only use it one way, which can make life easier. But as an implementor of either a SGML or ODA conforming system, I have to handle everything by the book (the exact book depends on whether its a particular SGML application, ODA DAP, etc, etc). If you want to make your own subset and then exclaim how wonderful the standard is, I suggest you read the a recent editoral in (I think) CD ROM End User with the title something of the form "SGML-like is not SGML". I believe I said something on my writing an SGML parser in a couple of days, and a preprocessor to take care of the minimization in another two, to show a client "what we could do with SGML". That does not count as "cheat" in my vocabulary. If you allude to my "start with only a few hundred lines of Emacs lisp code", as cheating, I think you're unfair. I see no need for you to protect your own hide so fervently, or indeed any need to attempt to damage mine. Nowhere have I said that it is extremely simple to make a full-fledged conformant SGML system, just that you can get something useful off the ground in a smallish amount of time. Customers like to see something before they pay you enough to make the tax people turn into vampires. About prototypes, you could say "application-like is not application", and try to denounce prototypes per se. I don't do that. I also don't leave a customer with the prototype. As you're on some mailing lists I'm also on, you have already observed to which extent I insist on following the standards involved. I'm quite annoyed at your comment. We have already taken this to private mail. The above is not meant as a polemic intended to be replied to, ad infintum. -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, , therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427 --