🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.text.sgml
Article #330

Re: What about the DTD

#330
From: Erik Naggum
Date: Tue, 23 Oct 1990 04:15
103 lines
5413 bytes
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,	<erik@naggum.uu.no>, <enag@ifi.uio.no>
  therefore I post.	+47-295-8622, +47-256-7822, (fax) +47-260-4427
--
Technical Details
Message-ID: <ENAG.90Oct23051446@hild.ifi.uio.no>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bloom-beacon!eru!hagbard!sunic!nuug!ifi!enag
References: <Yb8TVny00VsAM7bEoo@andrew.cmu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <ENAG.90Oct23051446@hild.ifi.uio.no>
Date: 23 Oct 90 04:15:01 GMT
References: <Yb8TVny00VsAM7bEoo@andrew.cmu.edu>
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