Groves processing in OpenJade

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi,

In a previous message, I mentioned the grove manager and how we could
implement the requirement to have an "environment" grove node element. In
this present message, I'll explain why currently OpenJade grove manager is
limited by some implementation constraints. How addressing these constraint
with a solution may also affect DSSSL-2 future specifications and probably
the other SGML based specification like Hytime (because of the grove plan
definition).

A) OpenJade's current grove manager is based on static structures:
----------------------------------------------------------------
In the actual grove manager (i.e. spgrove) all elements or grove nodes are
implemented as structures. For example the groves elements are defined as:

struct GROVE_API ClassDef {
  ComponentName::Id className;
  const ComponentName::Id *allPropertyNames;
  const ComponentName::Id *subnodePropertyNames;
  ComponentName::Id childrenPropertyName;
  ComponentName::Id dataPropertyName;
  ComponentName::Id dataSepPropertyName;

  static const ClassDef sgmlDocument;
  static const ClassDef sgmlConstants;
  static const ClassDef dataChar;
  static const ClassDef element;
  static const ClassDef attributeAssignment;
  static const ClassDef attributeValueToken;
  static const ClassDef pi;
  static const ClassDef sdata;
  static const ClassDef documentType;
  static const ClassDef entity;
  static const ClassDef notation;
  static const ClassDef externalId;
  static const ClassDef externalData;
  static const ClassDef subdocument;
  static const ClassDef nonSgml;
  static const ClassDef message;
};

B) A grove plan based implementation requires a dynamic structure
------------------------------------------------------------------
to be able to fully implement a grove plan interpreter, we need to:
a) add to the DSSSL document (i.e. a SGML document) new interpreter
processing for the sgml-grove-plan element's content. Thus, the
DssslSpecEventHandler::startElement(StartElementEvent *event) and the
DssslSpecEventHandler::endElement(EndElementEvent *event) respectively part
of the DssslSpecEventHandler.cxx file are to be update to include the
processing of the new grove plan elements.
b) The grove element static structure needs to be replaced by a dynamic
structure where classes inserted in the dynamic structure are defined in the
grove plan.

C) The grove data model should be based on the composite pattern
---------------------------------------------------------------
The composite pattern (ref: Gamma & al.) allows to manipulate elements and
elements collections. A good example of an API based on the composite
pattern is definitively not the DOM model from W3C but surprisingly the ADSI
API from Microsoft. In fact, this latter is probably the nearest API to a
versatile grove engine. this is natural, because it is an interface to
directory services... a natural grove (based on directory objects - nodes,
classes, inheritance and whole part relationship)

As an example, a grove manager API could contain nodes objects. To each node
object is associated a property collection. The basic node object API or
interface allows to get/set properties. This could be packaged as a class.
Then, a collection manipulation API or interface allows the insertion,
deletion, update of new nodes in a collection. This again, could be packaged
in a class. If the node's collection class inherits from the basic node
object class, we have create a composite pattern configuration.

As a very simplified an not complete example:
class node
{
	class (classid);
	get (property,value);
	put (property, value);
}

class node_coll: public node
{
	add (node*);
	remove (node*);
	update(node*);
}

This dynamic structure inspired from the composite pattern could be used to
build a tree like dynamic structure. Thus, the grove plan interpreter would
first create a class grove (mapping the inheritance relationship between
elements) and then build the document grove. If the grove definition
language allows to map elements to node's class, the process could even be
simplified by an automatic mapping of semantic classification of the
document's element. For instance, if the element <legal> is mapped to the
legal_document class, the constructed grove will contain a legal-document
grove node. From the class grove, we can a) find that this element is an
instance of the legal-document class, and b) deduce that the legal-document
is inheriting from the sgml-document class and be able to answer to both a
query on the sgml-document and the legal-document classes.

Conclusion: to fully implement at the same time a semantically rich and
dynamically defined grove, we need:
a) to modify the DSSSL document parsing to decode a grove plan and construct
a dynamic structure of defined classes, classes inheritances and required
property collection (for each class). This could be done with a composite
pattern based structure containing the classes, classes inheritance and
property collection definitions.
b) to parse the document with a dynamically created grove where each
elements are related to the class grove.

The new dynamic structure based on a composite pattern could be used then
for both the class definition and the document grove.

Amendments to the SGML property set could be proposed within the DSSSL-2
activities to relate elements to classes so that groves with semantic
content could be built. For instance, if the <legal> element is related in
the grove plan definition to the legal-document class, and if the
legal-document class is inheriting properties from the sgml-document class,
we then added rich semantic meaning to groves and therefore semantic queries
based on this kind of grove.

Hope, this short document may help understand the issues involving OpenJade
implementation and related impacts on the future DSSSL -2 specs and even
more the impact to related technologies like Hytime.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist