In message <391C8BAC.A96FDA75@eng.sun.com>, 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
version-controlled.
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
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
------------------------------------------------------------------------
Porsche Boxter. You and a friend. Nine dream days from
Napa Valley to Beverly Hills. Provided by CarsDirect.com.
Click to enter.
http://click.egroups.com/1/3993/4/_/444287/_/958450730/
------------------------------------------------------------------------
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 : Mon May 15 2000 - 21:26:47 PDT