Skip to main content
Jump to: navigation, search


< Higgins
Revision as of 20:23, 22 February 2008 by (Talk | contribs) (The model for attribute models)

Today, IdAS defines a set of special interfaces for accessing a context's model elements. It may be better to not define special interfaces for this purpose, but instead simply re-use the existing interfaces that are used to access normal information within a Context (nodes and their attributes).

Following is a proposal which shows how these model nodes might look. To illustrate the proposal, we start by showing how an instance of a person looks (nothing new) and then examining the model nodes that govern instances of nodes and attributes:

A person

Example of an instance of a person node.

  • Java type: some impl of INode. The context provider implements this class
  • getNodeID() returns: the contextually unique ID for this person
  • getAttributes() returns: typical attributes about this person (things like a homeAddress and phoneNumber)
  • getType() returns: an identifier for this person's model node. assume it's called “”
  • getTypeNode() returns: some impl of INode, assume it returns a PersonModel.class

A person's model

Now, say we look at the “person model” node we saw above (we got this either by calling INode.getTypeNode(), or INode.getType() followed by IContext.getTypeNode()), we see (NOTE: this node is a model element):

The "top" node model

Ok, now let's look at the instance of the node called “”. This is simply the top-level model definition for all node model hierarchies. Thus it contains model definitions for things common to all nodes:

The model for node models

What defines a node model node? This does:

The model for model elements

Finally, here's the model for model elements:

Note the recursive nature of getType and getTypeNode above. We could instead return null or throw some well-known exception.

An attribute model

Now for fun, let's look at an attribute's model, and follow that. We'll take the example of “”:

The model for attribute models

And here's that the node identified by “” looks like:

Then of course we have value models. Again from the bottom-up, here's a node that describes a value type called <TODO: finish this>

<TODO> needs to be a way for people to extend NodeModel and AttributeModel such that they can add their own elements (like displayName, icon, etc.>

<TODO need to be able to specify min/max cardinality on each attributeType associated with a specific node model so we can preserve the ability to say "person nodes must have at least one surname attribute value, and may have a telephone number" without causing all instances of surname to be min=1

Back to the top