Re: [unrev-II] Current Proposals

From: Lee Iverson (
Date: Mon May 15 2000 - 21:18:44 PDT

  • Next message: Eugene Eric Kim: "Re: [unrev-II] Current Proposals"

    In message <>, Eric Armstrong writes:
    >At yesterday's meeting, Jack and Howard, based on
    >a meeting with Doug, proposed that source documents
    >(HTML, source code, etc.) would be translated into
    >an XML-based OHS format and stored in the OHS
    >repository in that format. [Note: That is the XML
    >model I have been assuming.] The documents are then
    >transcoded for display.
    >Lee Iverson then proposed a different idea, where the
    >OHS-XML document does not carry the information
    >directly, but instead consists of pointers and links
    >into the original document. The original document
    >remains intact. [That sentiment echoes design concepts
    >proposed in a message by Sandy Klausner.] He further
    >proposed that the source document could be transcoded
    >to produce that "OHS wrapper", rather than translated.

    I wasn't really trying to propose a different default strategy, but an
    alternative strategy in certain cases.

    One of the design requirements (both from bootstrapping and
    sociological points of view) is that the development OHS/DKR we are
    developing interoperate with current open-source development
    "best-practices". One of those best-practices is CVS/CVSWeb.

    Now when we combine this observation with the reality that it is
    unlikely that software development will be engaged in using XML-tagged
    source code we are left with the strategy of using some transcoding
    layer on top of the source to allow for unambiguous referential
    hyperlinking into sources (and that is the context in which I
    mentioned SDS).

    So, the reality of the situation can be summarized thus:

        1) Source code with CVS is already archived and
        2) A CVSWeb (or similar) interface provides a Web-enabled view of
           the full version-controlled hierarchy.
        3) SDS (or similar markup system) provides the ability to
           unambiguously refer hyperlink *into* source code and
           follow sorce cross-references.

    It would seem to me to be wasteful to OHS-ize the sources every time a
    revision is made simply in order to be able to make references in
    discussions or documents. Moreover, it would be counterproductive to
    require developers to "buy-in" to the OHS environment, a possible
    consequence of requiring ingestion, in order to participate in
    development discussions.

    As I said, it was somewhat hair-splitting of me to make the point.
    But, put simply: when we expect documents to be dynamically changing
    outside the OHS system and those documents are both version-managed
    and indexable, then it may make sense to define the OHS-document
    interface as an ongoing transcoding process rather than as a
    repeated translation and ingestion.

    Lee Iverson SRI International 333 Ravenswood Ave., Menlo Park CA 94025 (650) 859-3307

    Porsche Boxter. You and a friend. Nine dream days from
    Napa Valley to Beverly Hills. Provided by
    Click to enter.

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:26:47 PDT