home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1289 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.3 KB
  1. Path: sparky!uunet!ralvm13.VNET.IBM.COM
  2. From: drmacro@ralvm13.VNET.IBM.COM
  3. Message-ID: <19930111.141443.972@almaden.ibm.com>
  4. Date: Mon, 11 Jan 93 17:09:16 EST
  5. Newsgroups: comp.text.sgml
  6. Subject:  "full SGML support"
  7. Disclaimer: This posting represents the poster's views, not those of IBM
  8. News-Software: UReply 3.1
  9. Lines: 44
  10.  
  11. In the discussion of FrameBuilder, the phrase "full SGML support"
  12. has been bandied about.  The problem with the term is that anyone
  13. who claims it currently is lying, if we take it literally, because
  14. no-one supports the LINK feature (that I know of) and no-one supports
  15. CONCUR, that I know of, thus, no-one provides "full" SGML support, and
  16. if anyone claims to support those, I'd want to see proof of how they
  17. do it before I accepted their word for it.  I would not accept parsing
  18. of valid LPDs with no other LINK-related function available as "support",
  19. for example.
  20.  
  21. I wonder if we shouldn't agree as a community what "full SGML
  22. support" really means so that we have a consistent and reasonable
  23. standard for applications, a standard that is not onerous but that
  24. is complete enough to be useful and worth advertising.
  25.  
  26. I would accept the following definition of "full" as reasonable:
  27.  
  28. o Support for all *required* features of SGML
  29. o Support for variant syntaxes and any set of capacity values
  30. o Support for SUBDOC
  31.  
  32. I would like to see support for the following as part of "full",
  33. but wouldn't push the matter:
  34.  
  35. o Support for the APPINFO statement in SGML declarations (minimally,
  36.   making the information defined on APPINFO available through one
  37.   or more application interfaces).
  38. o Support for LINK.
  39.  
  40. I would not insist on CONCUR, despite Michael Sperberg-McQueen's arguments
  41. to the contrary.
  42.  
  43. Perhaps we can define "complete SGML support" to mean support for
  44. *all* aspects of ISO 8879.  This would prevent pedants like Erik
  45. and myself from getting difficult when people claim "full" SGML
  46. support and give us, the community of SGML users, a somewhat
  47. reliable method of judging applications using a reasonable set
  48. of criteria.
  49.  
  50. Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
  51. Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
  52. Network Programs Information Development     Phone: 1-919-543-7091
  53. IBM Corporation
  54. Research Triangle Park, NC 27709
  55.