- From: Len Bullard <cbullard@hiwaay.net>
- Date: Mon, 27 May 1996 10:26:57 -0500
- To: john@eco.powernet.co.uk (John Middlemas)
- Cc: "hyper-theory@math.byu.edu" <hyper-theory@math.byu.edu>, "www-html@w3.org" <www-html@w3.org>
>>Check out http://navycals.dt.navy.mil/mid.html and look for a language >>called Metafile for Interactive Documents of MID. > >I had a quick look at this, it is quite involved, but seems promising. Not for the timid, for sure. >>It uses chains of infoContainers as state machines for navigation >>of database content. The link traversals are gosub, goto, spawn and get. > >I think the database content you refer to is the pages out of a technical >manual. Could be any database for which a handler exists. I've been writing an example for the xeno declaration, and it essentially is just a function declaration, function, and named arguments of type string. >The goto looked like my FIRE command at first but there doesn't seem >to be the possibility of transferring INPUTS from one page to another. That would be a xeno, I think, although since this is an SGML/HyTime application, one could also statically define values for notation declarations or HyTime notlocs (notation locations). This is not a nice solution because they are static, so xenos would be preferred. > Also I am not sure if MID could run a page >purely for code reasons without displaying it. This too would be essential >because fast code only, programming Webs, must be integrated with everyday >browsing. Good question. I think a MID wouldn't be the best tool for that. It was designed to encode logical navigation, so it is very tied to the widget containers. >What is the equivalent of the URL in MID? A HyTime clink, ilink, etc. MID links don't work like URLs. A URL is simply a uni-driectional inlined link with some caveats for relative addressing. In MID, the links can be stored separately, on in pools, or local. These are HyTime link and location architectural forms which are subclassed to create the location types you need. A URL is roughly an SGML entity <!ENTITY myTarget SYSTEM "/foo/myrurl.txt" > It requires another location element type such as a nameloc which contains the entity name myTarget. The nameloc is refered to by some link type which could be the equivalent of an anchor. SGML rules for names and IDs force indirection. If you want a URL, you can use a HyTime notlink (notation link) which allows you to do what a URL does directly. >>The links can be strongly typed and are n-way. These links >>can be powerful because semantics can be assigned and >>used in functions, expressions, and xenoforms >>for calls to externals. > >Don't understand all this but calls to externals would not be necessary if >networks of richly connected Web neurons with small amounts of standard >internal code were used instead. Any external function could be performed by >these, which are also capable of modelling any n-dimensional curved space >(IMHO). Ok. I know a bit about neurons and petri-nets, etc, but I don't quite get that. Is this similar at all to the kind of thing that happens when a Netscape/JavaScript onLoad function fires? Can your network be simulated that way? >What I am really saying is that I believe the concept of Web neurons (which >is actually very simple) could be applied at all levels of computing, from >the way we build the hardware right up to the top application level and >indeed it is installed at the highest level of all - the brain. Sounds ambitious. Just a bit of philosophy: everyone I've seen who starts out with the "if we just start over and do it right approach" seems to hit a hard wall of legacy systems and "not invented here". In other words, the tiger is already in motion, so take care to get a good grip on the fur. :-) >If one simple system is used throughout then the average man might just >understand computers (and even be able to program them). >>It was created as a client language >>for long lifecycle behaviors (e.g, technical information). >>MID was designed to be interpreted or used as an >>intermediate transport language. It is verbose but >>it was meant to be human readable and reasonable >>to teach to humans. > >I think it has possibilities, and seems more advanced than HTML. It doesn't >really matter how you do it as long as there are no dead end blocks to stop >it working. I don't think there are with HTML. The biggest problem may be >altering server URL handler software. Yes. Well, we didn't have HTML or the WWW in mind when we designed it. The dead ends with HTML probably start in using a declarative root language. Things can get pretty complicated in that tree after a while. The HTML model has limits that begin to show as more folks try to add more functionality and cannot agree on it. HTML should be an architecture, not a DTD. >>Libraries can be built using SGML general entities >>and catalogs. It is ISO 8879 and ISO 10744 conforming. >>I realize that cuts little ice in the Web worlds, but this >>wasn't designed for the web or HTTP although it could >>work in that environment. Three working prototypes exist with >>the last built under the MS MFC. The US Navy designed >>it but it is an open specification. > >Is anybody planning to bring it to the Web? Maybe. It has been discussed, but more in terms of bringing it to the Internet or other networks not used by the public. The WWW is a subsystem of the Internet. Users of HTML may not be the same users as MID. For one, MID is harder to do unless an authoring tool is built for it. That is quite easy to build. Also, since MID is solidly built over ISO standards, some IETF'rs will reject it out of hand. And so it goes. The choice of a protocol for MIDs is really open at the moment. I don't know if HTTP/MIME is what is needed. It has been suggested that we use raw TCP/IP sockets, but this is not my area of expertise, so I defer on that. Nothing stops one from making a MID system that works across TCP/IP. It will be done more than likely, but that is something that depends on customer needs. If I were doing it, I would target it at enterprise applications. For that, it would be quite good in the same way that Visual Basic is. cheers, len bullard http://fly.hiwaay.net/~cbullard/
Received on Monday, 27 May 1996 11:29:22 UTC