Date: Wed, 15 Nov 2000 14:28:13 -0800

From:	Eric Armstrong
	eric.armstrong@eng.sun.com Reply-To: unrev-II@egroups.com

To:	unrev2, unrev-II@egroups.com

Subject:

Tuesday's meeting

In a continuation of Saturday's meeting, Ken Holman met again with several members of the OHS design team.

As a result of that meeting, the design focus is shifting away from "lets transcode every document into a common XML form" and towards "lets define the functional interfaces and only after that is done done figure out what XML is needed for data interchange."

As part of that shift, rather than conceptualizing the OHS as XML-versions of documents, we're thinking of it as a repository that contains pointers to legacy-documents plus whatever additional data is required to provide OHS services.

This focus strikes me as very promising. The strategy wins on several levels:

1. As Ken mentioned, it allows others to differentiate and innovate on the implementation, using different internal representations to provide the requisite functionality in a way that preserves interoperability.

2. It lets us think in terms of defining an abstract "viewer" for legacy documents. (E.g. word documents spreadsheets, diagrams, etc.) People who are close to those formats can build specific viewers, while the OHS provides a common ground for the additional data necessary to use them effectively.

3. As more interesting views are constructued, they are stored in the OHS. Over time, the OHS becomes more and more central, and legacy documents become secondary, the OHS therefore grows "organically" from its legacy-document beginnings.

4. As we discovered at Tuesday's meeting, the process of defining the requisite functionality and structures is tantamount to a specification (or anthropolical rediscovery) of Augment's "ontology". (It turns out that the "ontology" defines the functional interactions, as well as an abstraction-tree that leads naturally to an object hierarchy.) Casting the problem in these terms lets us use our ontology gurus (Jack and Howard) to advantage. They intend to start mining Augment documents in order to extract that ontology. (Eugene will use his Augment to HTML converter to make sure they get what they need.)

The original meanings of the terms had been something more along the lines of HyperScope is a mini-OHS that works with legacy documents, while the OHS was the full monty, or words to that effect. But the meanings that the terms intrinsically suggested to Ken make a lot of sense. They suggest an appropriate division into viewers, entities, and repositories.

And rather than having a "HyperScope" that one day evolves into a "OHS" (how do we know when it has happened?) we have both a HyperScope and an OHS on day one -- where the OHS starts small and grows larger, containing more flavors of HyperDocuments over time.

At the moment, we seem to have factored the problem in a way that lets everyone bring their skills to bear simultaneously on different aspects of the problem. Odds are good that we'll be able to continue down this road for awhile, and potentially make substantial progress as a result.

Sincerely,

Eric Armstrong
eric.armstrong@eng.sun.com