Cart
[Home] [By Thread] [By Date] [Recent Entries]
I'm not sure what the conclusion here is: o Only programmers should use systems o Only users should program systems and then how that translates to XML where o Any one can write an instance o Only some programs can process some instances What is the point exactly? Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] Every now and then I get back to computing history. Partially I do it to figure where things came from, but I'm always looking for something that looks like it might fit with XML. The passage below, quoted in Steven Levy's _Hackers_, is one such possible fit. --------------------------------------------- The ITS system is not the result of a human wave or crash effort. The system has been incrementally developed almost continuously since its inception. It is indeed true that large systems are never "finished".... In general, the ITS system can be said to have been designer implemented and user designed. The problem of unrealistic software design is greatly diminished when the designer is the implementor. The implementor's ease in programming and pride in the result is increased when he, in an essential sense, is the designer. Features are less likely to turn out to be of low utility if users are their designers and less likely to turn out to be difficult to use if their designers are their users. Donald Eastlake, "ITS Status Report", MIT A.I. Lab Memo No. 238, April 1972. (from Steven Levy's _Hackers_, 1984, p.127) ----------------------------------------------- Users of XML mostly aren't the hackers who inhabited the MIT AI Lab in the late 1960s and early 1970s, though I think that Donald Eastlake is the same person currently working on XML Digital Signatures. How does the development of a time-sharing program fit with the development of XML vocabularies? To me, it's in the "users are their designers and... designers are users." XML is a new opportunity for information users to structure the information they want to work with as they want to see it, not as defined by a "human wave" effort trying to nail down every data structure in sight. Markup fits well with incremental development. Formats no longer need to be punch cards, and users have opportunities to make changes on the fly. Sadly (to me), the software frameworks people are designing around markup aren't nearly as flexible. Developers seem to be writing code that couples tightly to data based on very limited possibilities for what that code might contain, though many larger frameworks offer "escape hatches" where they suspect such things are necessary.
|
