home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0093.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  3.3 KB  |  77 lines

  1. Submitted-by: stephe@mks.com (Stephen Walli)
  2.  
  3. In <1hbkbtINNmh8@ftp.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
  4.  
  5. >    i wanted to add some commentary to stephe's treatise (epic? opus?
  6. >kidney stone?). 
  7.  
  8. Angst.  And thanks for taking the time to read it. 
  9.  
  10. >    first of all, i think LIS are a good idea. as some of the readers
  11. >of this group know, i am the technical editor for an ECMA standard on
  12. >file system formats (its now DIS 13346!!). i ``had'' to change the draft
  13. >to follow essentially a thick/thin binding format. what this meant was that
  14. >there were prose sections that defined the semantics of the standard;
  15. > ....
  16. >it really
  17. >helps root out spurious details and you get a much better logical
  18. >consistency in the overall design. But, there are a few field names in
  19. >there because to get rid of them would have signficantly hurt the readability
  20. >of the standard; i was not willing to do that just for pedagogy's sake.
  21.  
  22. I agree very much with your statement about the ability to better specify 
  23. the standard, by stressing it and re-casting it. A couple of questions,
  24. because it sounds like you've been able to do something useful with your 
  25. LIS.
  26.  
  27. 1. I haven't seen your spec (and I know its electronically available :-)  
  28.    but how big is it wrt POSIX.1?  I think size and scope has a lot to 
  29.    do with some of the problems in POSIX. 
  30.  
  31. 2. I found the two book/two context problem really hurts usability.
  32.    ( I don't believe this is the simple publishing problem some people 
  33.     think it is.)  Are their similar concerns with your spec? 
  34.  
  35. 3. How many language bindings are there to your LIS? And what languages 
  36.    are they? 
  37.  
  38. 4. Have you seen the current POSIX.1/LIS and POSIX.16 C-binding? 
  39.    If so, what did you think?
  40.  
  41. >    to a large extent, this has happened to the posix committees.
  42. >someone has a good idea: ``test methods''! 
  43. >....
  44. >they will delay every useful
  45. >posix standard from 1-3 years for NO technical gain, they combine
  46. >in unpredictable ways with another experimental idea (thick/thin bindings),
  47. >and will probably drive 30-70% of the skilled volunteers out of the
  48. >standards process because of the huge increase of arbitrary BS such
  49. >folks would have to wade through just to stand still?' (actually, even if
  50. >put in such terms, it might have got through anyway because the
  51. >people on such over-arch committees TEND to be more concerned with
  52. >``purity of essence'' than with ``timely, useful standards''.)
  53.  
  54. To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
  55. done. It will go in front of the IEEE Standards Board in June. There are no
  56. test methods. To construct test methods, they should do so in an LIS form, 
  57. plus C binding. But then the standard is not yet in LIS form. Plain old 
  58. fashioned C. If I found out, as a poor individual programmer in the 
  59. industry, that this useful specification was being withheld by the IEEE 
  60. standards board because it didn't have this other thing (of NO value to 
  61. me as programmer) called test methods, I would yell VERY LOUDLY at ANSI, 
  62. which certifies the IEEE to produce standards. 
  63.  
  64. As always, my two cents. 
  65.  
  66. cheers,
  67. stephe 
  68.  
  69. ------------------------------------------------------------------------------
  70. Stephen R. Walli,       stephe@mks.com | Just say ``NO'' to anticipatory 
  71. Mortice Kern Systems Inc.              | standards. 
  72. phone: +1 (519) 884-2251               |
  73.  
  74.  
  75. Volume-Number: Volume 29, Number 93
  76.  
  77.