home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0293.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  10.0 KB  |  184 lines
  1. > But we are not discussing 'file servers' in general, but something
  2. > more specific and presumably over which we have more control: use of
  3. > MIME content identifiers to identify content-type in World-Wide-Web
  4. > and WAIS servers. Even in the case of file servers, while you might
  5. > not have control over the material offered, you do have control over
  6. > the description of that material as to which version of a purported
  7. > standard format the material might be in, and even, in some cases,
  8. > which profile of that standard might apply.
  9.  
  10. I remain extremely skeptical that you can exercise this level of control. I
  11. suspect that if you achieve any control whatsoever it will probably be arranged
  12. along axes that you haven't yet considered. (The most obvious one would be
  13. knowing package that produced the document as well as the version of its
  14. PostScript driver.) I think that if you try to arrange a particular sort of
  15. labelling now you will only find that things don't match up to it.
  16.  
  17. If in fact you do end up with some degree of control over version-specific
  18. usage it will _then_ be the time to add some additional parameters containing
  19. this information.
  20.  
  21. >> If I wish to retrieve the document, say to view it, I might want to
  22. >> choose the available representation that is most appropriate for my
  23. >> purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
  24. >> from an anonymous FTP archive, only to discover that it is in the
  25. >> newly announced Postscript level 4 format, or to try to edit it only
  26. >> to discover that it is in the (upwardly compatible but not parsable by
  27. >> my client) version 44 of Rich Text. In each case, the appropriateness
  28. >> of alternate sources and representations of a document would depend on
  29. >> information that is currently only available in-band.
  30.  
  31. >Even if this happens (I have strong doubts that it will since documents made
  32. >available for public retrieval tend to converge rapidly to lowest-common
  33. >denominator usage) you have failed to propose an alternative that solves this
  34. >usefully.
  35.  
  36. > Documents made available for public retrieval do not cannot 'tend to
  37. > converge rapidly to lowest-common denominator usage', because *old
  38. > documents do not go away*!
  39.  
  40. Nonsense. Documents (old or new) get revised when they fail to meet the needs
  41. of lowest-common denominator usage. Let's suppose I put up a document that uses
  42. a bunch of level 2 PostScript extensions. Let's further suppose that I emblazon
  43. it with dozens of labels indicating that this is the case. But all the
  44. labelling in the world will not make this document print on an old LaserWriter.
  45.  
  46. Regardless of labelling people will want to print the document. Maybe they will
  47. retrieve it and maybe they will not. I seriously doubt that most people will
  48. know what all this version stuff means (try asking the average user of a laser
  49. printer what version of PostScript is supports), so in most cases the labelling
  50. will be wasted effort. But regardless of whether they retrieve the document and
  51. it fails to print or they heed the labels, people will then complain.
  52.  
  53. As the author of the document I will be "encouraged" to provide a version that
  54. will work properly on the huge installed base of level 1 (or lower) printers. I
  55. then have three choices: (1) Build two documents, one at each level, (2) Build
  56. one document at the lower level, or (3) Build one document that works at either
  57. level. (1) is not useful since it means maintaining two copies of a document in
  58. almost the same format. (2) is totally reasonable, but the PostScript standards
  59. strongly recommend (3) and give numerous examples of how to make (3) happen.
  60.  
  61. I would therefore claim that the world will rapidly move to using (3), and
  62. makes most sorts of labelling entirely pointless.
  63.  
  64. > If there is diversity today in the
  65. > available formats for RFCs, tech reports and PhD theses, that
  66. > diversity can only get worse! It is foolish to think that the
  67. > diversity will diminish any time in the near future; certainly the
  68. > number of 'conference proceedings on CD-rom' is increasing, as people
  69. > want to share Mathematica documents, various forms of hypertext, audio
  70. > content and the like.
  71.  
  72. This supposed diversity is almost entirely illusory. In the early days of
  73. PostScript this was perhaps true, but things have now been worked out to a
  74. point where there's a large consensus behind what is acceptable PostScript
  75. usage and what is not.
  76.  
  77. In addition, the norms of acceptable PostScript usage are actually somewhat
  78. more restrictive than what appears in the specifications. This is largely due
  79. to the bugs that were present in early PostScript interpreters (problems with
  80. character set vector information come to mind here). This has resulted in a
  81. peculiar mix of feature use and non-use. Fortunately, there are relatively few
  82. glitches of this sort, and this has led to a situation where the problems are
  83. fairly well understood by the driver-writers in the PostScript community.
  84. Nevertheless, I would be the first to support an RFC that describes in some
  85. detail what sorts of PostScript usage are acceptable and what are not.
  86. (I'm more than willing to contribute to such a document; I just don't have
  87. time to write the whole thing myself.)
  88.  
  89. As part of my daily work I help maintain a portion of our product line that
  90. includes a full PostScript interpreter. As a result I deal with PostScript
  91. problems on a daily basis. And while there are still a couple of notorious
  92. offenders out there, most modern PostScript problems end up either being file
  93. corruption issues or missing header files -- things of this sort. In other
  94. words, the MIME encodings go a long way towards solving most real-world
  95. problems printing PostScript, and driver changes can solve most of the
  96. remaining problems.
  97.  
  98. > As for a proposal that 'solves this usefully', I have a fairly mild
  99. > proposal that, while it does not solve all of the problems in
  100. > interoperability, does reduce the amount of uncertainty:
  101.  
  102. > I propose (once again) that instead of saying 'application/postscript'
  103. > it say, at a minimum, 'application/postscript 1985' vs
  104. > 'application/postscript 1994' or whatever you would like to designate
  105. > as a way to uniquely identify which edition of the Postscript
  106. > reference manual you are talking about; instead of being identified as
  107. > 'image/tiff' the files be identified as 'image/tiff 5.0 Class F' vs
  108. > 'image/tiff 7.0 class QXB'.
  109.  
  110. All my objections still apply (you have yet to respond to a single one of my
  111. earlier points on this matter). I remain totally and completely convinced that
  112. this just causes numerous problems and solves absolutely nothing.
  113.  
  114. I will spare everyone the repitition of the numerous problems it causes -- they
  115. can get all that out of my earlier mail.
  116.  
  117. > > Finally, let me point out that I speak as one of the maintainers of one of the
  118. > > largest archive of TeX material available anywhere. This material has been
  119. > > available via MIME-compliant mail server (and of course FTP) for over six
  120. > > months now. This archive contains hundreds of PostScript documents as well
  121. > > as all sorts of other stuff. The problems you seem to think are endemic to
  122. > > this sort of services have yet to materialize.
  123.  
  124. > I think you need to take a longer-term and broader perspective than a
  125. > six-month experience with a single representation of document.
  126.  
  127. The archive has been online for about five years. (I just checked and there are
  128. three FTP connections going right now -- fairly light usage for midday.) Mail
  129. service has been available for three years or so. MIME compliance in the mail
  130. service was introduced six months ago. Some of my contribution to the
  131. development of MIME came from the experiences of setting up and maintaining
  132. this archive.
  133.  
  134. > We've been developing a document archive service that can cope with 20
  135. > years of collected electronic documents. We have not only Postscript 1
  136. > and 2, but also several versions of Interpress, and Press format, two
  137. > versions of DVI, revisable formats of 20 years of editor development
  138. > -- several versions of tex, latex, framemaker, microsoft word, tioga,
  139. > globalview, viewpoint, bravo, bravox, tedit, troff, interleaf,
  140. > wordperfect, etc, and images in multiple variations of RES, AIS, TIFF,
  141. > sun raster, pcx, macpaint, ad nauseum.
  142.  
  143. Have you deployed it yet? Do you have any operational experience at all?
  144.  
  145. > In trying to deal with a documents over the longer term, it has become
  146. > apparent that merely marking documents with a simple 'format' tag like
  147. > 'interpress' or 'postscript' or 'tiff' isn't adequate for most
  148. > purposes. Standards evolve over as short as a 5 year period; even the
  149. > method of internal tagging standard versions changes, and certainly,
  150. > it is impossible to rely on in-band version information for all
  151. > formats. 
  152.  
  153. As I have stated on numerous occasions, my arguments and comments on this
  154. matter are intended _only_ to apply to PostScript. I am fully aware that many
  155. formats do not include version information and this must be provided
  156. externally. There are also formats which provide internal versioning
  157. information but that information is known to be inconsistent. I remain totally
  158. in favor of providing this information externally as needed. But as usual you
  159. persist in trying to apply my comments in a larger context where we both know
  160. they are not valid.
  161.  
  162. PostScript is a special case -- a very very special case. It is a complete
  163. programming language for starters. This makes it impossible to do anything
  164. resembling a complete analysis of feature utilization. PostScript also is
  165. fairly unique in that it has a comprehensive and extensible internal mechanism
  166. for describing itself.
  167.  
  168. > I have more to say about the problem of 'external references' but I'll
  169. > save that for another message.
  170.  
  171. Fine.
  172.  
  173. > It would be nice to have a calm discussion about possible solutions to
  174. > these problems & hope you will forgo future sarcasm.
  175.  
  176. I'm going against my better judgement and replying to you despite the fact that
  177. you still have not responded with how you propose to solve any of the issues I
  178. have raised in earlier messages. Rest assured, however, that this is my last
  179. word on the subject until you begin to come to grips with the serious problems
  180. your proposal will cause us all.
  181.  
  182.                 Ned
  183.  
  184.