home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1286 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.2 KB
  1. Path: sparky!uunet!ralvm13.VNET.IBM.COM
  2. From: drmacro@ralvm13.VNET.IBM.COM
  3. Message-ID: <19930111.081057.248@almaden.ibm.com>
  4. Date: Mon, 11 Jan 93 10:46:04 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: <19930111.002@erik.naggum.no>
  10. Lines: 78
  11.  
  12. Erik brings up some interesting points and I think he's generally
  13. correct.  The abstract model I have in my mind for SGML systems
  14. is one where applications are separated from the data storage
  15. component (database) by a true SGML parser and entity manager
  16. that provides a completely-conforming SGML parsing "view" of
  17. the data and hides the details of how the data is stored.  On
  18. top of this layer is what we might call a "logical access
  19. interface" that only presents the resolved element tree view,
  20. augmented by knowledge of data entities, something like this:
  21.  
  22.  
  23.          Application Layer
  24.           :   A     : A
  25.           :   :     V :
  26.           :   :    Logical Access Interface
  27.           :   :     : A
  28.           V   :     V :
  29.          SGML Parser/Entity Manager
  30.                       : A
  31.                       V :
  32.          Data storage and access
  33.  
  34.  
  35. In this model, applications can either interact directly with the SGML
  36. parser and entity manager or interact with the logical access
  37. interface.  The first choice represents traditional "translator"
  38. applications where the application itself performs all document data
  39. handling (e.g., builds its own data structures for holding information
  40. about the document as it's processed).  The other option is a "query
  41. interface", where the knowledge of the document structure and content
  42. is held and managed by the logical access interface as a service for
  43. the application.  This effectively provides a more abstract view of
  44. the document data for the application.  This is the sort of view that
  45. data retrieval systems normally want.  How the creation of this view is
  46. implemented in practice is not important and could be via parsing of
  47. the document instance on demand if the parser is fast enough.
  48.  
  49. This is a very abstract model and the methods of implementing
  50. it are many and varied.  I'm not sure there's a meaningful
  51. difference between a system where SGML documents are parsed
  52. into a database (without loss of structural data or knowledge
  53. of data entities), from which all subsequent access is done,
  54. and a system where all data access is done against the raw
  55. SGML data itself.  As long as the SGMLness of the data is
  56. preserved such that it can be restored at will, it conforms.
  57. Note that this is different from using "SGML-like" structures
  58. or parsing SGML into a form in which some SGML aspects are
  59. lost, even if the structure is preserved.
  60.  
  61. For example, the definition of SFQL presented at SGML '92 had no
  62. mechanism for preserving knowledge of NDATA entities within
  63. element content.  Therefore, it fails the test defined above
  64. because there is loss of vital SGML information.  By the same token,
  65. if the validity of the data in an "SGML database" cannot be
  66. determined in exactly the same was as if the data was parsed
  67. normally, the database system fails.
  68.  
  69. I can see a tremendous utility in the library system Erik
  70. outlined, where a set of SGML access services are provided
  71. that make SGML applications independent of any given SGML
  72. parser or entity manager.  I suspect that the first generally-
  73. available (which may mean free) or well-defined set of functions
  74. will become a defacto standard.  It would be interesting to
  75. see such a library defined as part of OSF/1, for example, or
  76. as part of IBM's SAA architecture for application interfaces.
  77. The DSSSL standard may provide such a definition,
  78. I don't know, or it may provide sufficient definition of
  79. what such a definition would have to provide in terms of
  80. information about SGML documents to enable creation of a
  81. complete design in the abstract.  I would want to see such
  82. an interface defined outside the scope of any implementations,
  83. even if it is provided as part of a vendor product.
  84.  
  85. Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
  86. Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
  87. Network Programs Information Development     Phone: 1-919-543-7091
  88. IBM Corporation
  89. Research Triangle Park, NC 27709
  90.