Prior Art

This page is Copyright (c) 12 September 2004-2012 by Richard Urwin. All rights reserved.

Here are some ideas, probably patentable, which I have no intention of patenting.This page exists to record these ideas as prior art. If you want to implement them then please do so. A nod in my direction would be appreciated. No patent search has been done, so I do not certify that these ideas are indeed patentable. I specifically refuse you the right to patent them.

Hierarchical Filesystem

12 September 2004
I note that Microsoft is trying to produce a file system based on a relational database. In my view that's wrong-headed. A relational database is not as powerful as the hierarchical system that is used already. However there are some advantages to having all your data contained in an intelligent structure, (ie the structure itself is intelligent.)

There already exists an intelligent data structure: XML. I propose an entire filesystem that can be seen as a single XML document. There would be two difficulties in doing so: translating the data into a filesystem, and inserting the DTD/schema into the data.

The current standard file systems are hierarchical in nature, and can represent the upper levels of the document without serious difficulty. Tag attributes could be included as file attributes, or included as files with special names.

The advantage of implementing this system is that the data is intelligent; it holds its own structure. There is therefore a need to include the XML DTD in this system; although XML can exist without a DTD, that would not answer our requirements here. The current system, where a single DTD describes the entire document would be unwieldy when applied to an entire filesystem. Instead I propose that the DTD be described by an attribute to an XML node. That type of node may have a new type encoding for use in the higher level DTD. The attribute of the node would describe a path within the same XML document, or external to it, for the DTD to be used to parse the body of the node.

<test.c DTD="/home/richard/DTD/c-code">
main {}
<mypage.html DTD="">


For reasons of intelligibility I have left in the file extensions in that example. It is probably worth mentioning that the filesystem would not require that; but it would probably still be done, for the aid of the users and old utilities.

Subclassing of a DTD would be supported by an attribute on the node holding the DTD. An algorithm for merging the node contents with the superclass DTD will be needed, but is straightforward to design. Subclassing is required for context menus and other structure-based intelligence for external DTDs. It would also be used to provide system-wide DTDs that could be modified by individual users.

Another special node type, probably within a DTD, would be one that associated a style-sheet (or any other type of program) with a DTD. Such programs could then be accessed with a context menu.

There would be a number of attributes and sub-nodes which the user was not supposed to be aware of on a day-to-day basis. The DTD syntax must be extended to provide the ability to specify that distinction. This is straightforward to design, and could be provided in a subclass if an old-style DTD was to be used.

I am not necessarily specifying that XML and/or DTDs be stored in the filesystem. It may be more efficient to use a binary encoding, but such binary encoding would be isomorphic to XML and DTDs.

Telepresence by Non-isomorphic Virtual Reality

11 December 2011
Telepresence is used to control robots remotely. For example submarines work on the bottom of the ocean, but are controlled by people on the surface by way of closed-circuit television and a few joysticks and buttons. The military make use of similar technology for pilotless drone aircraft.

The disadvantage of telepresence is that there is minimal feedback to the operator. In addition controlling such things as mechanical hands using joysticks does not effectively use the operator's hand-eye coordination in the same way it is used day-to-day. It improves the operator's control if there is force feedback from the remote actuator, and if the operator is using the same hand motions as they are commanding of the remote actuator. So opening the operator's hand results in the robot's hand opening. Then this can be extended so that moving the operator's head results in the robot's camera moving in the same way. This is Virtual Reality.

Walking poses a problem for Virtual Reality. Wandering around when your attention is literally miles away is not a safe activity. It might be possible to suspend the operator so that the leg movements can be detected without the body moving, but such rigs are likely to be large and complex. There will be significant problems to solve. For example if the operator jumps then force feedback has to be removed from their feet. Their weight must still be supported by the rig, but there is nowhere on the body to apply it without the operator perceiving it as false.

Robots, however, seldom have legs. Using a walking motion to command robot motion would always be imperfect. On the other hand (literally) using a joystick for movement requires one hand to be free. In the most immersive of VR, the robot should have two hands; as a normal human, the operator is most efficient when he can use two hands (and ten fingers) to work. Movement has to be controlled by the legs, since they are the muscle groups that are free for the task.

Therefore, use the muscles and joints of the legs for movement, but map them to facets of the robot motion control. In the simplest implementation a cycling motion could be used to control a wheeled robot. In the most complex each joint might map to a different axis of motion. So the toe joints might control roll, the ankle joints pitch, the knee joints yaw and the hip joints forward and reverse. For the most accurate control the control action should be the same integral order as the control response. Hence a cycling motion to control forward speed. However this will be more tiring than controlling a different order. A car accelerator pedal controls acceleration, and cars are less tiring to drive than bicycles.

Graphical User Interface Design Integrated Into Application Under Development

16 March 2012
GUI design tools are complex beasts. They have to draw a representation of the controls and allow them to be moved and rearranged. Then they have to generate a program that produces exactly the same layout using a different algorithm. Designing a new application requires learning to use the resource designer and flipping back and forth between the designer, the editor and the application.

Therefore, use the application program being developed to generate its own interface. A framework library extends all GUI framework controls to support a "Design" flag. When this flag is set clicking the control brings up a context menu allowing the properties of the control to be set, or the control to be deleted, or other controls to be added to it. The configured resources are saved to a configuration file on program exit and reloaded on start-up. During development, the design mode is entered and exited via a menu option. This menu option is disabled in the final product and resources that are only required during development may not be loaded.

There are difficulties in providing click capability to pure layout objects (eg grids), but it should be possible to work around that. Maybe an unobtrusive handle could be added in design mode. Also a tree view could be made available. Such a thing is easy to produce; it's the layout that is difficult.

For extra credit, build an editor into the framework so that the underlying behaviour can be modified without stopping the app and flipping to the editor. That should be possible with an interpreted language such as Python, but rather harder in C. Note that the whole point is that this is not an emulation of the running program; it is the real thing.

Program Specific Languages

13 June 2012
There's a lot of talk about domain specific languages, and that's all well and good, and I dare say that it may help somewhat, in some cases. But although it makes addressing a problem domain easier, it does not guarantee a fit to 100% of the problems in that domain. And what do you do about a program that sits in two domains?

Here is some code, what language is it in?

glRotatef(15, 1, 0, 0);
glRotatef(45, 0, 1, 0);
glRotatef(g_fTeapotAngle, 0, 0, 1);
glMaterialfv(GL_FRONT, GL_DIFFUSE, colorBlue);
glMaterialfv(GL_FRONT, GL_SPECULAR, colorNone);

There is a huge amount of code like that around today; just list upon list of function/procedure/method/message/signal calls. Object orientation tried to ease the problem by making the methods stick to the data structures, but they are still just lists of methods calls and, generally, less well documented. The more progressive languages attempt to solve the problem by labelling the parameters, but that is hopelessly inadequate; we need a way to code these lists of method calls that is readable and writable.

So our libraries, as well as supplying a list of methods for us to call, should also supply syntax extensions to our language.

Learning the new syntax would be no harder than learning a new library, maybe easier since it makes more sense.

So we modify the langauge we use according to the work we are doing with it. If we use lists then we have syntax that makes working with lists easy. If we are working with relational databases then maybe we import SQL as native language. And if we are writing distributed code then multi-processing paradigms will be inherent in the language we use.

One language where this is seen is Forth. However the syntax of Forth is so basic that many of the advantages are not apparent. What I want to do is to do to the high level languages what Forth does to assembler.

It is not at all clear how to go about that right now. We could make the language extensible by adding parser targets and macro expansions, but that only goes so far; it will let us code those lists of method calls, but it will not let us make minute changes throughout the general language syntax. In order to do that, we would have to be able to modify existing parser targets, but finding some way to allow two random libraries to modify the same parser targets, would be a significant challenge.

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License