home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / text / sgml / 1270 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  5.2 KB

  1. Path: sparky!uunet!spool.mu.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!aun.uninett.no!nuug!ifi.uio.no!enag
  2. From: SGML@ifi.uio.no (Erik Naggum)
  3. Newsgroups: comp.text.sgml
  4. Subject: Re: Precedence of SGML Operators?
  5. Message-ID: <19930107.004@erik.naggum.no>
  6. Date: 7 Jan 93 19:31:51 GMT
  7. References: <1802@igd.fhg.de> <19921228.013@erik.naggum.no> <93005.142005U35395@uicvm.uic.edu>
  8. Lines: 90
  9.  
  10. I wrote:
  11. :
  12. |   ... which in a different language could have been explained by some
  13. |   arcane precedence rules at work; however, SGML has no notion of
  14. |   operators or of operator precedence rules as these terms are used in
  15. |   programming languages.
  16.  
  17. I may have been unclear, so let me try again.
  18.  
  19. The term "operator" as used in programming languages has no counterpart in
  20. SGML.  Programming languages specify actions, operations, to be performed
  21. as a result of executing the code.  SGML is a descriptive language, and has
  22. no notion of operations: Operations cannot be expressed in SGML alone.
  23. Therefore, there are no _operators_.  The concept "operator" comes from a
  24. different world, and is conceptually incommensurate with SGML's concepts of
  25. "occurrence indicator" and "connector".  Thus, there is no place for the
  26. concept "operator" in the SGML world at all.
  27.  
  28. In some programming languages, there are rules to disambiguate the semantic
  29. order among multiple operators in a given expression, usually known as
  30. precedence rules, modified by parentheses.  (These rules may be expressed
  31. in the grammar, but this is indistinguishable from binding directions and
  32. precedence rules to the language user.)  In SGML, parentheses are not used
  33. to form expressions, but _groups_.  In any given group, only one connector
  34. may be used (the semantics of using more than one is not defined by the
  35. language), so there is no issue of precedence among connectors, or of
  36. binding direction.  Moreover, by virtue of the rule that only one connector
  37. can be used in a group, the connector effectively refers to all tokens in
  38. the group, even though it syntactically occurs between individual tokens.
  39. (This means that the connectors can not even be understood as "binary".)
  40. Similarly, an occurrence indicator refers to the immediately preceding
  41. _token_ (a group is a token in this respect), and would have been a "unary
  42. post-fix operator" if the language had had operators.
  43.  
  44. We have therefore established that a connector refers to all tokens in a
  45. group using it, instead of the tokens between which it occurs, and that the
  46. occurrence indicator is unary and post-fix with respect to the token to
  47. which it refers.  This completely removes the concept "precedence" from the
  48. SGML world.  Similarly, we previously removed the concept "operator" from
  49. the SGML world.
  50.  
  51. This is why I said that there could've been some notion of precedence rules
  52. at work "in a different language".
  53.  
  54. Numerous people try to think if SGML as "code" with "operators" and all
  55. sorts of familiar programming-language and/or regular expression concepts.
  56. There are important similarities, which enable us to think of SGML things
  57. in terms of familiar concepts and apply well known algorithms and
  58. techniques to SGML grammars, such as ambiguous content models and regular
  59. expressions, but the differences are also important, and can only be
  60. ignored at the peril of those who do.  In fact, the differences are what
  61. makes SGML so elusive and hard to grasp for many people who would like it
  62. to be what they think it looks like.  That's how we can get questions which
  63. confuse the element structure (a hierarchy, with all the attendant tree
  64. terminology and access modes), with its linearization and fragmentation
  65. into the entity structure, and how people can spend lots of time figuring
  66. out that "ambiguity" in SGML isn't the "ambiguity" from language theory
  67. (where the equivalent term is "deterministic").
  68.  
  69. SGML isn't a programming language, and never the twain shall meet.
  70.  
  71. C. M. Sperberg-McQueen <U35395@uicvm.uic.edu> writes:
  72. :
  73. |   ... EN's remarks might lead one to believe that other SGML parsers
  74. |   don't have bugs; that would be a wrong conclusion.  Certainly most of
  75. |   the ones I've used have a problem here or there.
  76.  
  77. I regret if this was a possible interpretation.  What I actually thought
  78. and wanted to express was that with all the marketing and hype that the
  79. Sema Group puts out about how their parser and tools support more SGML than
  80. others, they should be even more diligent than others in making sure that
  81. the marketing matches the product, and they have put their head on the
  82. block voluntarily.  There is also a major difference between getting the
  83. grammar wrong, and having a problem here and there.  This is the difference
  84. between a bug and a design flaw.  (I'm painfully aware that products in the
  85. computer industry _never_ match their marketing, but that doesn't mean we
  86. should accept this state of affairs.)
  87.  
  88. Thanks to Ed Blachman for noting that a new version of Mark-It has been
  89. published with this violation of the standard rectified.
  90.  
  91. I hope this clarifies what I had in mind.
  92.  
  93. Best regards,
  94. </Erik>
  95. --
  96. Erik Naggum                 ISO  8879 SGML                    +47 295 0313
  97.                             ISO 10744 HyTime
  98. <erik@naggum.no>            ISO  9899 C                 Memento, terrigena
  99. <SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis
  100.