home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1269 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.9 KB
  1. Path: sparky!uunet!ralvm13.VNET.IBM.COM
  2. From: drmacro@ralvm13.VNET.IBM.COM
  3. Message-ID: <19930107.113434.441@almaden.ibm.com>
  4. Date: Thu, 7 Jan 93 14:33:13 EST
  5. Newsgroups: comp.text.sgml
  6. Subject: Re: SGML for data querying
  7. Disclaimer: This posting represents the poster's views, not those of IBM
  8. News-Software: UReply 3.0
  9. References: <1993Jan7.021616.11906@nuscc.nus.sg> <1993Jan7.142852.23671@infodev.cam.ac.uk> <19930107.090654.710@almaden.ibm.com>
  10.             <1993Jan7.180136.236@infodev.cam.ac.uk>
  11. Lines: 44
  12.  
  13. In <1993Jan7.180136.236@infodev.cam.ac.uk> Alasdair Grant writes:
  14. >
  15. >Thanks for your reply.  I just want to pick up on something - what do
  16. >you think about including features like comments, tag minimization,
  17. >and data tagging in a database?  If you don't, you aren't really storing
  18. >the "real SGML", but I honestly can't see the point of remembering that
  19. >tag of item X was minimized while tag of item Y wasn't.  Seems to me
  20. >that there is at least one level of SGML which gets in the way of
  21. >database applications, and ought to be stripped out in any importation
  22. >of SGML into a database.
  23. >
  24.  
  25. It's certainly technically possible to preserve all of that in
  26. a database if the needs of your system require it, but I wouldn't
  27. loose sleep over a system that didn't preserve comments.  Tag
  28. minimization can be re-applied algorithmically since the minimization
  29. rules are defined in the DTD, and features like shorttag and
  30. datatag are best left alone, since they are primarily concesions
  31. to the problems of data entry, not information identification or
  32. structuring, and therefore shouldn't enter into the equation.
  33.  
  34. Most of the folks I've talked to do not seem to consider the requirement
  35. that SGML source be normalized for database storage to be a problem
  36. in practice, and we know we can unnormalize it if we ever want to.
  37. You can get around the problem of preserving comments by providing
  38. elements whose defined semantic is to contain descriptive comments
  39. about the elements that contain them or define explicitly-descriptive
  40. elements for the sorts of things you normally use comments for,
  41. such as "file headers" that contain author information, change
  42. tracking info, copyrights, etc.  That is the approach we've taken
  43. within IBM.  I will not accept any arguments for preserving comments
  44. based on the needs of applications that use the data in comments
  45. for their own purposes.  SGML provides better places for such
  46. information, such as processing instructions, the APPINFO statement
  47. in SGML declarations, extra-SGML mechanisms unique to the
  48. application, and so on.  Since comments are, by definition, not
  49. part of the document content, and are not carried by the ESIS
  50. information, there is no strict requirement to preserve them.
  51.  
  52. Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
  53. Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
  54. Network Programs Information Development     Phone: 1-919-543-7091
  55. IBM Corporation
  56. Research Triangle Park, NC 27709
  57.