home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / text / sgml / 900 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  5.6 KB

  1. Path: sparky!uunet!cis.ohio-state.edu!ucbvax!RALVM13.VNET.IBM.COM!DRMACRO
  2. From: DRMACRO@RALVM13.VNET.IBM.COM ("Dr. "Eliot Kimber" Macro")
  3. Newsgroups: comp.text.sgml
  4. Subject: Data Representation in SGML
  5. Message-ID: <9207211343.AA07166@ucbvax.Berkeley.EDU>
  6. Date: 21 Jul 92 13:10:37 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Lines: 107
  9.  
  10. Darryll Raymond writes:
  11.  
  12. >In article <9207201503.AA25149@ucbvax.Berkeley.EDU>, DRMACRO@RALVM13.VNET.IBM.C
  13. >O
  14. >M ("Dr. "Eliot Kimber" Macro") writes:
  15. >
  16. >>I do know that I have yet to be presented with a data form or
  17. >>set of relationships that I cannot express in an SGML tag set
  18. >>coupled with complementary processing applied to that tag set.
  19. >
  20. >  Two comments.  First of all, computationally speaking, this isn't
  21. >saying much.  For if you allow yourself to use complementary processing,
  22. cthen it doesn't matter *how* you express the original relationships, or
  23. >which ones you do specify.  For you can smuggle all the complexity, as
  24. >well as any extra relationships you want, into your complementary processing.
  25. >If you start out with arbitrary computing power, it's not surprising that
  26. >you end up being able to do anything that's computable.
  27.  
  28. I think we may be talking at cross purposes and that perhaps I have
  29. misunderstood both what you were getting at and what your purpose
  30. is.
  31.  
  32. If your contention is that the representations and relationships
  33. definable *solely* in the semantics provided by the SGML
  34. language syntax as defined in ISO 8879 is not up to the
  35. task of data modeling in all the various ways that it might
  36. be done (the assumption being that some language could be
  37. invented that would allow that in some rigorous way), then I must
  38. agree.  SGML was not designed to be an all-encompassing data
  39. modeling language all by itself.  Quite the opposite.
  40.  
  41. SGML was designed to do two things:
  42.  
  43. 1. Separate as completely as possible information about document
  44.    structure and content (what things are and how they relate to
  45.    other things in the document structurally) from "formatting"
  46.    or presentation specifications needed to derive a particular
  47.    output rendering from that data.  Doing this enables re-use
  48.    of information in powerful ways.
  49.  
  50. 2. Define a rigorous syntax for the markup the enables point 1
  51.    such that any conforming SGML document will be parsed in exactly the
  52.    same way by any conforming SGML system.
  53.  
  54. The SGML standard is explicit in indicating that it is up to
  55. the processing application to define what the semantics
  56. of the data are.  This makes sense because different uses of
  57. the same data may use different semantics, thus SGML should
  58. not impose any single semantic expression on that data.
  59. What's missing is a standard way of expressing those semantics.
  60.  
  61. The SGML standard goes out of its way to avoid defining the
  62. language for defining any semantics about relationships (even
  63. IDREFs only tell you that two things are connected--they don't
  64. tell you why).  This is because the SGML standard forms the
  65. basis for a general data processing infrastructure upon which
  66. more complex applications can be built.  As Erik said, and I
  67. agree 100 percent, the value of SGML is that it makes building
  68. applications on top of an SGML system easy (or even possible,
  69. where they were impractical before).
  70.  
  71. Note that the draft DSSSL standard (ISO 10179) *does* define a
  72. standard language for describing the relationship semantics between
  73. arbitrary data elements in SGML documents.
  74.  
  75. I would suggest that instead of rejecting SGML because it
  76. doesn't define semantics, that you propose an SGML language
  77. and related set of processors that do everything you want
  78. them to.  This is what HyTime does.  HyTime defines the
  79. data elements it recognizes *AND* the associated processing
  80. that must be performed.  Thus, interchange is achieved
  81. at the processing level because the HyTime standard
  82. defines what processing must be done and how semantic
  83. relationships are defined and decoded.
  84.  
  85. By the same token, a publishing system based on DSSSL
  86. and SGML enables interchange at the processing level
  87. because the DSSSL specification is a specification
  88. of the semantic relationships defined in a standardized
  89. language.  Any conforming DSSSL processor will reach
  90. the same semantic conclusions about a given document.
  91.  
  92. What I have learned from HyTime is that any way of expressing data,
  93. any set of semantic relationships, can be defined in terms of
  94. "architectural forms", which codify the types of things your system
  95. deals with, coupled with definitions of the required processing
  96. associated with each architectural form, thus codifying the semantic
  97. relationships between different forms.  My forms may use SGML
  98. functions like IDREF to enable connections between elements, but my
  99. architecture definition defines what two elements being connected means
  100. semantically and in terms of processing that either must be performed,
  101. can be performed, or cannot be performed.  I can, in other words,
  102. standardize, using SGML as the language for expressing my
  103. architectural forms, the representation and processing of any data
  104. form or relationship I want to.  The processing part of my standard
  105. can be expressed textually, or it could be expressed in some general
  106. procedure definition language.  In fact, I could use DSSSL
  107. specifications to specify my "semantic architectural forms".  SGML is
  108. not a requirement for doing this, but SGML provides a powerful and
  109. convenient language for doing it (and for me, writing content models
  110. is second nature at this point).
  111.  
  112. Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
  113. Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
  114. Network Programs Information Development     Phone: 1-919-543-7091
  115. IBM Corporation
  116. Research Triangle Park, NC 27709
  117.