Cart
[Home] [By Thread] [By Date] [Recent Entries]
Speaking only for myself, and not finding co-author Tim Berners-Lee... Kurt Cagle writes: > But my interest here is not to look back at what might have been but to look > forward to what could be. Applying the "Principle of Least Power" seems to > imply that given the choice of two travel services that take a query for > flights between Seattle and New York ... > - One of which will return a list of scheduled flights sorted by time; > - The other of which will return a list of flights that have seats actually > available that I can be reimbursed for under my employer's travel policies, > ordered by a tradeoff across time convenience, intermediate stops, and > price, with opportunities to upgrade the seat using my personal frequent > flyer miles flagged; My reading is that the Rule of Least Power says that both of these are just dandy, presuming that the lists are in both cases represented in some simple declarative format such as XML, JSON, or even structured plain text. The rule doesn't comment at all on the differences between the shorter and the more detailed list mentioned above, and presumably the 2nd option is more useful to a broader range of users. What the Rule of Least Power does say would be a lot worse is sending back a pile of Javascript that, when run, would output either of the above lists. With either of your options, a broad range of programs can easily parse the lists, and can extract useful information. If instead what you have to do to get the list of flights or the list of flights that meet your employer's criteria is to run Javascript, wait to see whether the Javascript does anything, and then parse the results, then you can expect your list will in fact be accessible in fewer places. The Rule does not discourage using either Turing-complete languages in general or imperative languages in particular where they are the best means of capturing behavior, some algorithm. What it does encourage is the transmission of data and information (and logic or algorithms when practical) in simple declarative forms when those simple forms are good enough. On the Web, it's a good thing if that data is given a URI that can facilitate access to and resuse of that information (in this case, your flight lists.) So, use Javascript, etc. to build the presentation and integration logic of your Ajax applications, particularly where better options aren't available. However, when those Ajax applications are consuming (summar or detailed) lists of flight times, send those around in some simple reusable format like XML, RDF, JSON, csv, text, etc. -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 --------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
