Group Notebook - page 8 of 42

Sun Apr 27 21:47:50 1997 (GMT)

Comments and Ideas on Basic Notebook Object

Thoughts on General Notebook Object
(notes from Al's private notebook)

Basic Definition: Notebook dates and stores static objects and allows later viewing of these objects. Optionally provides mechanisms to detect if objects have been modified (tampered with).

Our common design approach is to have two parts: engine and user interface (client/server model)


Basic Notebook Object

(Al's thoughts on smallest useable subset)
Submitted by the Interface MIMETYPE: of data
LABEL: description of object (string)
DATA data (or URL)
Generated by the engine DateTime: object is submitted
Author: who the engine authenticated
Object ID: for engine use

Extensibility is provided in two ways
Extensibility of Object Content:
 Both the Interface and Engine can provide additional key/value pairs to the basic notebook pairs. Examples include Notarization/value, Parent/value, AccessPermissions/value, Applet/value, etc.
Implementations are free to include any additional key/value pairs not defined by the basic object.
All engines are required to store all key/value pairs and to return them to a requesting interface.
Some engines may understand and be able to exploit or generate additional key values.

Extensibility of Object Type:
 The interface can use the MIMETYPE field to define a new type of object (not defined by existing MIME types). These could correspond to experiment specific or project specific objects. If an interface receives a MIME type it does not understand, it is free to ignore it or respond in the same manner as a web browser.


Comments on key values for the Basic Notebook Object

MIMEType - specifies the MIME type of the raw data. Besides the standard MIME types, we could define a MIME type "text/URL" that would specify that the "Data" value is a URL
that points to the data.

Label - a user supplied string that can be used to describe the object. For binary data this may be the only string that is searchable.

Data - the (encoded) data follows this keyword. An interesting question is how do we specify termination of the values following a keyword?

DateTime - the engine acquires a trusted value of the date and time either from its own clock or from a time server and places this value in the object. The time must specify the time zone.

Author - the engine has authenticated the person or instrument who is submitting this object. The value of this key is a string that identifies the submitter within this engine. It is suggested (but not required) to provide the submitter's name and any other information such as a digital signature that would uniquely identify the submitter.

Aside:
Note that it is up to the engine how to authenticate the submitter. In some cases, such as private notebooks kept on laptops, users may not want the hassle of authentication and simply want the engine to assume the submitter's name (or is willing to accept information from the Interface on who the entry is from).

Object ID - the engine requires some means to identify objects submitted to it. While this identifier could be stored anywhere inside the engine, this specification states that the identifier be placed inside the object. The Object ID must be unique within the engine and may be (but is not required to be) unique outside the engine.

Aside
I would like to suggest that we use URLs as Object IDs in our project. These could be relative or absolute inside any given Notebook implementation. Using URL's fits nicely with abolishing parentIDs.
Objects in the notebook (such as an image) may be referenced by several pages. Thus there is no clear parentID to a given object. It makes a cleaner, more flexible design to have the parent object have to reference all its children. This becomes pretty natural if objects are referenced as URLs. For example, referencing an image object on notebook page becomes
(IMG SRC=ObjectID)


Publish tools
It is very desireable to leverage all the HTML publish tools that are being developed around the world. Can we create a design that would allow users to create notebook entries with these tools? Can the engine be able to accept the input of these tools through their publish interface.

Encoding of Values
Base64 encoding for binary data and use of ASCII for values is important to permit transfer of notebook objects to new computers with different data formats. Use of something like multi-part MIME makes it easier to describe to Records Management staff how the notebook entires are able to survive long term storage. DOE has mandated that RM archive for 25 years all notebooks created at the labs. This includes paper and electronic notebooks.

Because of the 25 year archive time-period there is a problem, if notebook entries are stored encripted. There is a high probability that the encription key will be lost and the data will (by default) be lost along with it. The user may forget what encription key he used for a notebook by the time he turns it in to RM. The user may die or be unreachable before the 25 year time limit expires. RM may loose the key. If the decription key is archived with the notebook, then the encription serves no purpose. For these reasons I would like to suggest that entries not be stored encripted. (They may be transmitted encripted).

Al Geist

Group Notebook - page 34 of 42

Added Mon Apr 20 23:24:05 1998 (GMT) Jim Myers

Draft updated NOb Spec

Here's an update of the Java language NOb spec reflecting our discussion about parentNOb and case sensitivity. We still need to define "reserved" fields. I also added another function called keys() that allows you to query a NOb about what key-value pairs have been defined. (Previously, there was nothing in the spec that would allow you to discover user defined keys!) I'd also propose that the interface become INOb instead of NObLike to match Java naming conventions that have appeared since we started.

The Notebook Object Interface

The NOb is the data standard used by the notebook client and editors to pass information back and forth. A NOb consists of key-value pairs. There are several mandatory key-value pairs. (These values are of interest to the notebook client and engine for managing NObs.) There are also "reserved" key-value pairs that are optional, but whose meaning is defined in the specification. User-defined key-value pairs can also be added.

A NOb has four defined operations. The get method returns a value object given a key. The put method lets you assign a new value to the key. The remove method deletes a key-value pair (mandatory keys will be set to their default values by the remove method). The keys() function returns a Java Enumeration of all the defined keys (necessary to discover the existence of user-defined keys.) The Java definitions for these methods are shown below. 

  
	public interface INOb { 
		public Object get(String key); 
		public Object put(String key, Object value); 
		public void remove(String key); 
                public Enumeration keys(); 
	}
The table below is a list of all mandatory key-value pairs.

"authorName" a string identifying the author string
"objectID" a notebook engine specific object identifier string
"dateTime" the date and time as returned by the toGMTstring method of the Java Date object string
"label" a user-defined summary of the NOb. Useful for searching on non-text NObs string
"dataType" the MIME type/sub type of the NOb data string
"data" a string or byte array containing the data string or byte []
"dataRef" if the data value is null, the dataRef value is a URL pointing to the data itself string

The values of all mandatory key-value pairs, except "data", are guaranteed to be non-null. The default value of all mandatory pairs is the empty string - "". The "data" value can be set to null to indicate that the data is stored externally, pointed to by "dataRef".

Reserved key-values are to be defined. One class of these will deal with digital signatures. All fields of the form -sigN where N= 0,1,2,3,... are reserved to carry digital signature information about the specified field.

Jim Myers