home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / text / sgml / 921 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  3.5 KB
  1. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!malgudi.oar.net!chemabs!sun1.is.battelle.org!bclcl1.im.battelle.org!idiws1.idi.battelle.org!idicl1.idi.battelle.org!raudabaugh
  2. From: raudabaugh@idicl1.idi.battelle.org
  3. Newsgroups: comp.text.sgml
  4. Subject: Re: It's Not Just for Text Anymore
  5. Message-ID: <1992Jul22.221732.1@idicl1.idi.battelle.org>
  6. Date: 23 Jul 92 03:17:32 GMT
  7. References: <710783547snx@sgmlinc.com> <CABO.92Jul14222524@kubus.cs.tu-berlin.de> <23254A@erik.naggum.no> <BrrMAL.4HK@watdragon.waterloo.edu>
  8. Organization: IDI-Dublin
  9. Lines: 57
  10. Nntp-Posting-Host: bidiao
  11. Nntp-Posting-User: raudabaugh
  12.  
  13. In article <BrrMAL.4HK@watdragon.waterloo.edu>, drraymon@watdragon.waterloo.edu (Darrell Raymond) writes:
  14. > In article <23254A@erik.naggum.no>, Erik Naggum <erik@naggum.no> writes:
  15. >> 
  16. >>Especially harmful is ignoring things that turn out to be more essential
  17. >>than the researcher thought.  This happens over and over, and I'm very
  18. >>skeptical of anyone who argues that X is non-essential and therefore not
  19. >>worth considering.  
  20. > 
  21. >   Thank you, Erik.  I'll repeat this to anyone that considers my problems 
  22. > with SGML as being non-essential.  :->
  23. > 
  24. >>I'm willing to concede the point that the structure is the
  25. >>essence, but SGML is in fact concerned with the linear representation,
  26. >>and not with the structure per se.
  27. > 
  28. >   This is the communications-protocol view of SGML.  Would it be correct 
  29. > to say, then, that the structure per se is captured in the DTD?  Or in
  30. > both the DTD and some external programs?  Or just the external programs?
  31. > Or just not at all? 
  32.  
  33. I take point with the above.  SGML is describes a document in a tree structure.
  34. The document is then non-linear, instead it becomes 2D.  Also, a very important
  35. feature is versioning or redlining (which I don't know the level of support SGML
  36. has).  This makes a document more 3D.  A very important part of publishing is
  37. to produce the most current version but also prior versions.
  38. >     
  39. >>I use SGML to define the syntax, and embed the semantics in
  40. >>the application 
  41. > 
  42. >   Ok. This is not what a data model does, unfortunately for those who 
  43. > thought that SGML was a data model (and perhaps that was only me).  A 
  44. > data model defines semantics and is mostly uninterested in syntax.  The 
  45. > relational model, for instance, defines what happens when you apply 
  46. > operators to a relation (i.e., the semantics of the operators), but could 
  47. > care less how you choose to represent the relation or the operators.
  48. > 
  49. >   What I hear Erik saying is that "the marked-up document is portable,
  50. > but the meaning of it is anybody's guess".  This is directly due to
  51. > the embedding of semantics in applications, and is the primary reason 
  52. > that, without support from some data model, SGML will result in 
  53. > non-portable, application-dependent documents.  
  54. > 
  55. > -Darrell.
  56.  
  57. An SGML doc is not self-describing alone to the outside world without the DTD.
  58. And yes, SGML docs without internal DTDs fly about all of the time.  Can the DTD
  59. describe the semantics about itself so that duplicate SGML docs don't end up
  60. consuming space-probably.  Can it describe the semantics about relationships
  61. between other docs that have the same DTD-maybe.  Can it describe outside
  62. relationships to other docs-why?  This is not what SGML is for nor should it be.
  63.  
  64. George Raudabaugh
  65. -- 
  66. George Raudabaugh               Project Leader
  67. Information Dimensions, Inc.    raudabaugh@idicl1.idi.battelle.org (work email)
  68. 5080 Tuttle Crossing Blvd.      
  69. Dublin, Ohio  43017             (614) 761-7309                     (voice mail)
  70.