home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / text / sgml / 1345 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.4 KB  |  77 lines
  1. Newsgroups: comp.text.sgml
  2. Path: sparky!uunet!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!SGML.news
  3. Date: 21 Jan 1993 18:06:52 -0500
  4. From: David Peterson <xyvi!davep@uunet.uu.net>
  5. Message-ID: <9301212306.AA01773A@dylan.local>
  6. References: <1993Jan15.003346.27802@news.eng.convex.com> <DGD.93Jan15114033@csd.bu.edu> <1993Jan16.051234.29089@news.eng.convex.com> <9301192217.AA00521@dylan.local> <1jkap2INNndl@rs2.hrz.th-darmstadt.de>
  7. Subject: Re: The definition of `DTD' (was: Re: WWW: a HyTime application?)
  8. Lines: 67
  9.  
  10. Joachim Schrod writes:
  11.  
  12. > Subject: The definition of `DTD' (was: Re: WWW: a HyTime application?)
  13. >
  14. > YEAH!
  15. >
  16. > Now we now, what a DTD ****really**** is, don't we?
  17. >     ``parameter-entity-replacement closure of the
  18. >         document type declaration's
  19. >     document type declaration
  20. >     subset.''
  21. > (Please note the nice doubling of the term DTD^H^H^Hdocument type
  22. > declaration. Isn't it almost literate?) This explanation is easy
  23. > readable and immediately understandable. For all those folks out
  24. > there who have always said `SGML is way to complex to grasp, we just
  25. > want to handle our documents in a structured way' -- bah, that is not
  26. > true, we just should tell them!
  27. >
  28. > Really, I'll save this article (Message-ID: <9301192217.AA00521@dylan.local>)
  29. > and will show it everybody who asks me why SGML is not more widely
  30. > recognized and more widely used than today.
  31. >     Hmm, perhaps he or she will know the reason then...
  32. >
  33. > --
  34. > Joachim
  35.  
  36. Sorry, Joachim.  I didn't invent the vocabulary, I just try to use it as
  37. correctly as I can.  In fact, there is some shorter/easier-to-understand/more-
  38. precise vocabulary (all three at the same time!) being developed and used by
  39. some people (including me), but for the benefit of those out there that haven't
  40. been exposed to the new jargon but do know the old, that's the way I wrote it.
  41.  
  42.     o  I didn't try to define or even to explain "what a DTD
  43.        ****really**** is".  Once the commment wording is corrected,
  44.        "DTD" is not involved--only "document type declaration".
  45.     
  46. I've drafted an article on "what a DTD really is"; if it's rejected for
  47. publication, I'll probably post it on the newsgroup.
  48.  
  49.     o  There are things called "document type declaration subsets";
  50.        every document type declaration has exactly one.  "Document
  51.        type declaration subset" has another meaning which precludes
  52.        its unqualified use in this particular context, since I was
  53.        trying to avoid ambiguity.  (I'll avoid boring everyone with
  54.        a discourse on the two meanings of the phrase, unless there
  55.        is a general clamor for it.  :-) )
  56.  
  57.     o  Goldfarb doesn't seem to like to distinguish between a character
  58.        string containing entity references and the character string
  59.        that results when those references are replaced by the replacement
  60.        text of the referenced entities.  I do; I find that many people
  61.        who don't make the distinction consciously get tripped up by
  62.        faulty intuition.  "Parameter-entity-reference-closure" means
  63.        the string that results when the parameter entity references are
  64.        replaced by the content of the referenced entities, any parameter
  65.        entity references in the resulting string are similarly replaced,
  66.        and such replacement recursively continued until there are no
  67.        parameter entity references.  "Closure" used in this way is common
  68.        mathematical terminology and is usually puzzled out correctly by
  69.        non-mathematicians; I know of no other concise term.
  70.  
  71.  
  72. Dave Peterson
  73.  
  74. xyvi!davep@uunet.uu.net
  75.  
  76.  
  77.