[Fwd: RE: [unrev-II] Digest Number 282]

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Mon Nov 20 2000 - 15:16:34 PST

  • Next message: Eric Armstrong: "Re: [unrev-II] The very medal"

    An interesting comment from the head of the
    jcorporate (espresso) project...

    -------- Original Message --------
    Subject: RE: [unrev-II] Digest Number 282
    Date: Fri, 17 Nov 2000 14:49:41 -0500
    From: "Sandra Cann" <scann@prodigy.net>
    Reply-To: <scann@jcorporate.com>
    To: <eric.armstrong@eng.sun.com>


    Just curious if you had realized that our eContent is a major step in
    direction described.

    1. it enables "content" to be presented in hierachical, tables, or other
    internal representations to provide the requisite functionality in a way
    that preserves interoperability

    2. it enables viewing any type of document, pdf, crystalwriter, word
    etc, as
    well as dynamically generated, and web applications/data. We have built
    datawarehousing tools to work with eContent to facilitate presentation
    legacy data.

    3. exactly. Additionally, as other pieces are integrated, the content
    becomes also the email system, corproate forms, and discussion forums,
    other data stored as part of integrated web applications. Spiders and
    searching/indexing are key.


    > Message: 11
    > Date: Wed, 15 Nov 2000 14:28:13 -0800
    > From: Eric Armstrong <eric.armstrong@eng.sun.com>
    > Subject: Re: 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.)
    > 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 -------------------------~-~>
    Create your business web site your way now at Bigstep.com.
    It's the fast, easy way to get online, to promote your business,
    and to sell your products and services. Try Bigstep.com now.

    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:

    This archive was generated by hypermail 2b29 : Mon Nov 20 2000 - 15:27:13 PST