Comments on ideas from Tim's MIT stay

Nice clean UDI camp: the UDI is a name for the query. If the query can be derived from the name somehow, and without implying a particular software tool to be used, so much the better. But think of persistence of information: do you want names to be compatible with SQL for the next century?

Quoting scheme: see proposal .

Commercial viewpoint: I hope this does not offend Brewster, but I hope, probably in vain, that the commercialists will stay out of the Web world. Selling information is like selling air and water to me, though of course you need to pay the people who provide the information. Your comment already points out some of the bad side-effects of selling per access, or worse, tariffs per type of information or per item! Like: today's newspaper is 10CHF because there is this item in it which everyone wants to know about.

Freezing queries: why do we need the distinction? Is a frozen copy a query from a frozen data base or a stored copy of the results of a live query? in the latter case, the UDI is just the UDI anyway.

Date information: surely important, but if you query, say, libraries, then it might be much more complex.

Argo etc. Are there people interested in the consortium idea?

On Argo requirements :

Form filling: here we go into a real can of horrible worms. I think this is a perfect case for a next layer. The UDI will simply explode and not live very long. See indirect nodes .

Multiple formats: of course, but the example is bad: surely one can persuade the bus lines to provide the machine readable form somehow...(at least in the future)

Application launching: Yes.

Complex interaction: the web should get you to the information, nothing less but nothing more. Then one could launch an application based on EDI to provide the bookstore's form and make the order.

Client history: Maps are certainly needed.

Client software update: notification of version differences does not need to be part of the protocol, the version numbers fly across with each access. Servers should never be concerned with versions of browsers, (only of the HTTP protocol), Browsers can have very different functions from one version to the next without using a different protocol version. This is a non-issue.

Forwarding: see indirect nodes.

Native interfaces: the question is not so much whether that is powerful enough as whether that is maintainable.

Self-contained browser: true, but it makes for a big application, and may not do as good a job as native converters which can be launched. The configuration problem can certainly be solved, and it may be easier than building and maintaining built-in format handling which may never be completely compatible.

RC