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.)
Ken also pointed us towards a better use of the terms
"HyperScope", "HyperDocument", and "OHS". He intuitively
(mis)undestood them to mean the viewing engine (HyperScope),
the repository (OHS), and the thing viewed (HyperDocument).
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.
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/2/_/444287/_/974327281/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 14:38:12 PST