home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1291 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.1 KB
  1. Path: sparky!uunet!vnet.ibm.com
  2. From: wohler@vnet.ibm.com (Wayne L. Wohler)
  3. Message-ID: <19930111.160155.422@almaden.ibm.com>
  4. Date: Mon, 11 Jan 93 16:38:20 MST
  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.             <19930111.081057.248@almaden.ibm.com>
  11. Lines: 48
  12.  
  13. I agree with what Eliot and Eric have said about the need for an
  14. abstraction of the SGML information using an interface definition
  15. through an applications interface of some kind.  I tend to think of the
  16. SGML parser/entity "interface" as an export/import cycle into and out of
  17. the data storage.  This data storage is accessed through Eliot's Logical
  18. Access Interface for applications that support it.  The SGML "interface"
  19. is used by any other SGML application that cannot make use of the
  20. logical access interface.
  21.  
  22. Why have a logical access interface?  Why not use the SGML data as the
  23. data storage?  Efficiency is one reason.  Backward compatibility with
  24. current product code is also another reason.  In my thinking, it also
  25. does away with concerns for markup minimization and entity structures,
  26. although it cannot lose ignored marked section information or comments
  27. (I believe Eliot and I have a minor disagreement on this).  At one level
  28. I think that the semantics which may be accessed across this interface
  29. must be flexible, depending on the nature of the application and the
  30. "wit" of the developers; I can see some real value to a standard here
  31. that many different products may plug into.  In any case, this
  32. abstraction need need not mean a loss of important semantics if the
  33. underlying data storage has the semantics necessary to carry the
  34. necessary SGML information.
  35.  
  36. What is the necessary SGML information?  There is one definition today,
  37. that is ESIS.  It is defined as that information which the SGML standard
  38. indicates must be available to the application, no more, no less.
  39. Unfortunately, given this definition some information that even a basic
  40. SGML application may need could not be included ... like the name of
  41. SDATA external entities.  The DSSSL group is planning to support this
  42. ESIS definition in its work.  We have asked for a few additions to the
  43. ESIS set to support our requirements.  In addition, DSSSL also supports
  44. what we are calling ESIS+ which contains all the information necessary
  45. to recreate the SGML datastream, including ignored marked sections,
  46. comments, tag specification strings, etc..
  47.  
  48. The model is that DSSSL systems and DSSSL applications on these systems
  49. may choose one or the other to work with (with appropriately defined
  50. behaviour for both cases).  Are there other public definitions of the
  51. "necessary" SGML information?  Every SGML product intrinsically supports
  52. some view of what is necessary or unnecessary based on the information
  53. the application has access to.
  54.  
  55. Wayne L. Wohler                   Internet:  wohler@vnet.ibm.com
  56. Dept G82/910M                     IBMMAIL:   USIB29WX@IBMMAIL
  57. Publishing Solutions Development             Phone: 1-303-924-0470
  58. IBM Corporation
  59. Boulder, Colorado  80301-9191
  60.  
  61.