CowDb 2 API, RoleML

We need to first identify which roles will have a small footprint and which may not, which requires a bit more metadata to be supplied by the CowdbFactory's plugin method. Once that is done, we can make the add and make methods a tad smarter.

Add and make must also look at the map node which will hold the new node. If the map node support embedding other nodes and the role of the new node is identified as small, then we will embed the new node in the map node. Otherwise the new node will be given its own space on disk and a direct reference will be added to the map node.

The goal here is two fold. First, we put are taking the decision to embed or not to embed a node out of the hands of the developer, who has enough other things to deal with and would rather not be concerned with this issue. Instead, the designer of a map role makes the determination about having the role support embeded nodes or not and ask the designer of all roles to determine if a new role is small or not. Using the CowDb 2 API then becomes much easier to learn and to use, as well as becoming much cleaner.

The second goal is to minimize the XML representation of a graph of nodes. The role is used as the element name and we will need only a few attributes:

• The name of the node.
• The well known name of the node.
• The immutable name flag.
• The headline (for COODBMS).

Direct references need not be represented in XML. However, in the case of symbolic references we will need an XML element. Again, the role becomes the element name and we will need a few attributes:

• The name of the handle.
• The immutable name flag.
• The symbolic reference.

We also need to handle attribute values and custom roles. This will require additional API on the App class for XML binding and XML expression. So even though we only need XML transformations for JOODBMS, this has to be driven all the way down to CowDb for a clean implementation.

RoleML seems to be a good name for this markup language. Note that it does not have a fixed schema, as new roles can always be defined which carry their own unique content. The alternative would be to just use node and handle as the element names and carry the role as an attribute. But that breaks the original spirit of extensibility and makes for really ugly xml, especially as the role maps so very nicely to the XML element name.