home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / text / sgml / 1349 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.1 KB
  1. Path: sparky!uunet!ralvm13.VNET.IBM.COM
  2. From: drmacro@ralvm13.VNET.IBM.COM
  3. Message-ID: <19930124.090452.202@almaden.ibm.com>
  4. Date: Sun, 24 Jan 93 11:51:46 EST
  5. Newsgroups: comp.text.sgml
  6. Subject: Re: FrameBuilder
  7. Disclaimer: This posting represents the poster's views, not those of IBM
  8. News-Software: UReply 3.1
  9. References: <9301131516.AA18603@mingus.techno.com> <1993Jan14.004718.28458@informix.com>
  10.             <1993Jan14.194453.20233@informix.com>
  11. Lines: 31
  12.  
  13. In <1993Jan14.194453.20233@informix.com> Robert Hartman writes:
  14. ...
  15. >Perhaps, but I'll settle for a flat ASCII representation with standardized
  16. >tags, and a strict separation of formatting information from content.
  17. >It's simpler.  It will do.  But even with this simple architecture, look
  18. >how long and difficult the process has been to deveop a standard!
  19. >
  20. >There are hordes of utilities of all kinds that already accept and
  21. >operate on files with the proposed SGML text format.  What you may gain
  22. >in response-time using a binary format, you lose in interoperability on
  23. >the fly.  Binary representations are by no means an unqualified win.
  24.  
  25. I wanted to register my agreement with Mr. Hartman.  Viewing the use
  26. of SGML as *only* an interchange form between authoring systems
  27. that "hide the tags" is a shortsighted view.  My own view is that
  28. high-function editing of SGML, compared to other tasks that having
  29. a standardized, human-readable language for structuring text enables,
  30. offers the smallest total benefit in author productivity, viewed over
  31. the total set of tasks and problems faced.  Not to
  32. say that authoring isn't important, but that it isn't the only thing,
  33. and that having a nice editor does not solve the most costly problems
  34. in large enterprise information development, such as supporting
  35. multiple output forms, data interchange on a wide scale, standardization
  36. of presentation styles, preservation of investment in data, and
  37. so on.
  38.  
  39. Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
  40. Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
  41. Network Programs Information Development     Phone: 1-919-543-7091
  42. IBM Corporation
  43. Research Triangle Park, NC 27709
  44.