home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / text / sgml / 1343 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!uicvm.uic.edu!u35395
  2. Organization: University of Illinois at Chicago
  3. Date: Thu, 21 Jan 1993 15:20:53 CST
  4. From: C. M. Sperberg-McQueen <U35395@uicvm.uic.edu>
  5. Message-ID: <93021.152053U35395@uicvm.uic.edu>
  6. Newsgroups: comp.text.sgml
  7. Subject:  sgml support and diff return code of 0
  8. References: <9301141548.AA19133@mingus.techno.com>
  9.  <1993Jan15.192630.4767@informix.com> <93018.171821U35395@uicvm.uic.edu>
  10.  <1993Jan19.023707.18716@informix.com>
  11. Lines: 47
  12.  
  13. Robert Hartman writes (quoting me):
  14. > >the standard says very clearly that an end-tag inferred by the parser
  15. > >behaves the same way an end-tag explicitly given in the input stream.
  16. > >If we require SGML processors to preserve that distinction from import
  17. > >to export, we really are requiring something more than SGML support from
  18. > >them.
  19. >
  20. > If you can write a parser that can do this correctly in all cases, more
  21. > power to you.
  22.  
  23. I'm not sure what you mean by 'this' -- if you mean 'infer the
  24. existence of an end-tag in the SGML document', then any conforming
  25. SGML parser can do it.  The standard defines quite clearly when a tag
  26. is omissible or not and how a parser can recognize the omission of a
  27. tag.  So it's not magic.  It's not even one of the areas in which
  28. different parsers differ substantially in their interpretations of the
  29. standard.
  30.  
  31. > From what little I know about parsers, it's would seem to me to be much
  32. > easier to get one to pass the diff test than it would be to verify that
  33. > another makes all the right guesses.
  34.  
  35. Easy, perhaps:  all you have to do is save the input file.  My argument
  36. was not that it's hard to preserve the input, but that it's logically
  37. inconsistent to insist that an implementation of a standard preserve
  38. distinctions which the standard defines as not having any legitimate
  39. significance.
  40.  
  41. It's as though one insisted that a C compiler had to produce object code
  42. from which the source code could be regenerated, and the regenerated
  43. source code had to have all the comments, the white space, the macro
  44. definitions, and the newlines of the original source, as well as having
  45. trigrams in exactly the places where the original source had trigrams.
  46. Otherwise we are going to tell all our friends and colleagues that the
  47. C compiler is not fully conformant.
  48.  
  49. Since the C standard specifies that a parser cannot require a user to
  50. use two spaces where one would suffice, or interpret two spaces
  51. differently from one (outside of literal strings), some might argue
  52. that a *conforming* C compiler *cannot possibly* preserve the information
  53. that one, or two, or seven, spaces were used here, or here, or here.
  54. Even if it's legal for a compiler to retain that information somehow,
  55. it would surely be rather strange to say that *only* a compiler which
  56. did that should count as fully conformant, which is what your
  57. original proposal boils down to for SGML parsers.
  58.  
  59. -C. M. Sperberg-McQueen
  60.