THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
rodwelch@pacbell.net


S U M M A R Y


DIARY: January 29, 2000 07:17 AM Saturday; Rod Welch

Colloquium #4 capability to improve "improvement"; XML Editor design.

1...Summary/Objective
2...Document Management Through Journaling and Citations
3...Tool to Improve Improvement
4...Does Scaling Up of Common Intelligence, Editing Create New Problems?
5...Augment Small Scale Enterprise to Improve Solving Big Problems
6...Start DKR with Core Capability, Grow Organically
7...Editing Core Capability for DKR Improves Alphabet Technology
.....Customizing Editor to User Preference - Extensibility
.....Extensible XML Editor to Store Source Code Supports Customizing
.....Extension Cord Architecture
.....XML Editor Literate Style Hierrchial Programming Capabilities
........Summary Linked to Detail
........Double Contain Comments and Code; Collapse, Expand Hierarchy
8...Millennium Project Illustrates Problem Solving of CODIAK, Versioning
9...Privacy Issues Presented in Colloquium Class 4

ACTION ITEMS.................. Click here to comment!

1...How does this relate the design for document management on 000125?

CONTACTS 

SUBJECTS
Colloquium Unfinished Revolution,
Objectives, Collective IQ
ABC Improvement Model
Document Management
Improving Improvement, Continual Learning
Scale Impacts Value of Everything, Engelbart
Too Many SDS Links Solved by Intelligence Summary
Augment Small Scale Capabilities, Group, Individual
Core Capability of DKR, Engine of Knowledge
Editing Core Capability
Add Capabilities Organically Serially
Phased Introduction of Capability
Plan Needed for Guidance
Risk DKR Failure War Stories
DKR Failure Need Redundancy Reduce Impact Bumbling

2417 -
2417 -    ..
2418 - Summary/Objective
2419 -
241901 - Follow up ref SDS 12 0000, ref SDS 11 0000.
241902 -
241903 - The forth class in the Colloquium at Stanford discussed Doug's ideas
241904 - for journaling and citations to manage documents. ref SDS 0 2955  The
241905 - Millennium Project illustrates problems that can be solved with the
241906 - DKR capability. ref SDS 0 4028  Adam Chayer explained tools for
241907 - improving the improvement process. John Werneken sets out a problem of
241908 - potential chaos that might occur if everyone edits common documents,
241909 - which reflects issues of scale cited by Doug Engelbart. ref SDS 0 0876
241910 - John proposes that the DKR project initially augment small
241911 - capabilities which enhance the ability to address large problems.
241912 - ref SDS 0 0865 Eric Armstrong recommends that an XML Editor should be
241913 - the core capability of a DKR, ref SDS 0 3383, and that users should be
241914 - able to customize functionality, which reflects design of Medit.
241915 - ref SDS 0 3600  He submits requirements for the XML editor to manage
241916 - programming comments, which is, also, needed for managing knowledge.
241917 - ref SDS 0 0957
241918 -
241919 -
241920 -
241921 -
241923 -  ..
2420 -
2421 -
2422 - Progress
242301 -  ..
242302 - Document Management Through Journaling and Citations
242303 -
242304 - Received ref DRT 1 0001 from John Werneken explaining the forth class
242305 - in the Colloquium at Stanford.
242306 -
242307 - John relates Doug's explanation in the Colloquium of having developed
242308 - in the 1970s a "journaling" method to manage internal documents, and a
242309 - method of "citing" external documents.  Evidently Doug's methods or
242310 - concept is to permit common editing and version control. ref DRT 1
242311 - 5032
242313 -  ..
242314 - John notes that the Internet now supports some of this capability,
242315 - but without common editing and version control.
242317 -  ..
242318 - This capability was reviewed on 991222 from Doug's paper on Groupware.
242319 - ref SDS 4 2040
242320 -
242322 -  ..
242323 - Tool to Improve Improvement
242324 -
242325 - John liked Adam Chayer's discussion on using a tool for improving
242326 - improvement, and how this capability can be developed. ref DRT 1 7308
242327 -
242328 - John looks forward to hearing other views on Adam's presentation.
242329 - ref DRT 1 3432
242331 -  ..
242332 - ABC problem analysis, seems to be one of the processes for continual
242333 - improvement by segmenting relms of capability, as reviewed on 991222.
242334 - ref SDS 4 3961   This reflects ISO requirements for continual learning
242335 - reviewed on 950721. ref SDS 1 2846
242337 -  ..
242338 - CODIAK seems to offer an "intelligence" capability that supports the
242339 - ABC improvement process, ibid. ref SDS 4 0786
242340 -
242342 -  ..
242343 - Does Scaling Up of Common Intelligence, Editing Create New Problems?
242344 -
242345 - John asks about the result of large numbers of users converging on the
242346 - same document?  Chaos, too much stuff to be useful, to much "petrified
242347 - Portman grits" postings as now infect the somewhat similar project of
242348 - slashdot.org's postings ? ref DRT 1 4828
242350 -  ..
242351 - On 991222 Doug's paper on Groupware reviews suprising results from
242352 - scaling factors. ref SDS 4 1596  On 951103 too much of good thing, is
242353 - generally harmful. ref SDS 2 4015
242355 -  ..
242356 - This was discussed on 000120. ref SDS 6 2345
242357 -
242358 -      [On 000307 Jon Winters asks for "war stories" of DKR efforts that
242359 -      fail. ref SDS 20 4928
242360 -
242362 -  ..
242363 - Augment Small Scale Enterprise to Improve Solving Big Problems
242364 -
242365 - John recommends that the Colloquium and Bootstrap focus on the small,
242366 - the ad hoc, augmenting specific tasks of a small group of people
242367 - voluntarily associating to address a specific issue - as opposed to
242368 - Millennium-style focus on macro ideas or "All Voices Being Heard"
242369 - concepts involving huge communities. ref DRT 1 6478
242371 -  ..
242372 - This aligns with John's earlier suggestion on 000120, ref SDS 6 3712,
242373 - leading to initial objectives for augmenting capability to conduct a
242374 - productive meeting or phone call. ref SDS 6 3071
242375 -
242376 -     [On 000225 John argues for markets to solve energy problem rather
242377 -     than command and control of an economy managed for "fairness."
242378 -     ref SDS 18 0897]
242379 -
242380 -
242381 -
2424 -

SUBJECTS
Core Capability of DKR, Engine of Knowledge
Add Capabilities Organically Serially
Phased Introduction of Capability
Plan Needed for Guidance
Risk DKR Failure War Stories
DKR Failure Need Redundancy Reduce Impact Bumbling
Single Core Function Start Project, 000129, Eric Armstrong

3109 -
311001 -  ..
311002 - Start DKR with Core Capability, Grow Organically
311003 - Editing Core Capability for DKR Improves Alphabet Technology
311004 -
311005 - Eric Armstrong's letter today requests ideas on the nucleus for
311006 - building a DKR. ref DRT 2 0001  He recalls that Adam identified a
311007 - great nucleus, and asks what should be the elements of the nucleus?
311008 - ref DRT 2 6930
311009 -
311010 -     Eric does not set out the "nucleus" Adam presented.
311012 -  ..
311013 - Eric addresses in general terms requests for preparing development
311014 - planning on 000120, ref SDS 6 0848, and again on 000124. ref SDS 7
311015 - 8960
311016 -
311017 -     [On 001025 Doug Engelbart submits project launch plan; a core
311018 -     function seems to be Hyperscope for translating, and OHS for
311019 -     linking different types of computer files. ref SDS 23 BDU6
311021 -  ..
311022 - How does this relate to document management submitted on 000125?
311023 - ref SDS 9 3867  On 000124 Jeff Miller proposed starting with Doc
311024 - Management. ref SDS 7 3867
311025 -
311026 -     [On 000208 Eric asks how to integrate email and hyperdocuments; he
311027 -     also requests for suggestions for the core capability of DKR.
311028 -     ref SDS 15 8960]
311030 -      ..
311031 -     [below, Eric sets XML Editor as core capability. ref SDS 0 3600]
311032 - ..
311033 - Eric relates advantages of creating a single-function core
311034 - module to get started -- the project's "Hello World" version. Adding
311035 - on to that a bit at a time seems to be a good strategy for
311036 - "organically" growing the system, especially when there is a plan for
311037 - adding features on a regular schedule. (Where adding a feature is
311038 - event-dependent, rather than time dependent. In other words, you plan
311039 - on adding feature B when feature A is complete, not in month M.),
311040 - ref DRT 2 3036
311041 -
311042 -     [On 000131 Jack Park working on an XML editor. ref SDS 14 0866]
311044 -      ..
311045 -     [On 000208 Eric discusses hacking a nucleus. ref SDS 15 2345
311046 -
311047 -
311048 -
311049 -
311050 -
3111 -

SUBJECTS
Architecture, Editor
Requirements, Open Source, Extensible, XML
Customize Tools for User Preference
XML Encoding, 001024
Java Based XML, 000129
Apache Editor, 000129
Adept, 000129

3909 -
391001 -      ..
391002 -     Customizing Editor to User Preference - Extensibility
391003 -     Extensible XML Editor to Store Source Code Supports Customizing
391004 -
391005 -     Eric's second letter, ref DRT 3 0001, explains ideas for editing
391006 -     capabilities, described as "architecture."
391007 -
391008 -     Core capability of the system seems to be an editor which provides
391009 -     OHS features, per discussion in Eric's first letter, above?
391010 -     ref SDS 0 3622
391012 -      ..
391013 -     How does this relate the design for document management on 000125?
391014 -     ref SDS 9 3867
391015 -
391016 -        Will the editor give people the tools to manage documents?
391017 -
391018 -         [On 000130 Eric cites extensible stuff to solve learning curve
391019 -         issue. ref SDS 13 5060]
391021 -          ..
391022 -         [On 000208 Eric asks for suggestions on what core capability
391023 -         of DKR should be. ref SDS 15 8960]
391025 -          ..
391026 -         [On 000131 Jack Park working on an XML editor. ref SDS 14
391027 -         0866]
391029 -      ..
391030 -     Eric points out that a goal for a project to maintain source code
391031 -     in XML is an extensible XML editor -- one in which you can
391032 -     subclass existing code to modify it's behavior and then use the
391033 -     subclass in place of the original.  That way, you can change not
391034 -     only the menu arrangements and keystroke assignments, but the very
391035 -     operation of the editor itself. (The major benefit of that
391036 -     strategy is that allows building up a repository of editor objects
391037 -     that operate in ways that are familiar to a variety of users.  The
391038 -     resulting "editor construction kit" lets you build the editor of
391039 -     your dreams, or at least one you are familiar with.), ref DRT 3
391040 -     5822
391041 -
391042 -          [On 000130 customizing facilitates learning. ref SDS 13 3828
391044 -           ..
391045 -          [On 000423 extensibility seems to be used differently from
391046 -          customizing the program. ref SDS 21 5033
391048 -      ..
391049 -     This capability in Medit produced SDS.
391051 -      ..
391052 -     Eric lists two possibilities...
391053 -
391054 -       1.  Apache editor, modifying it to achieve the desired level of
391055 -           extensibility. ref DRT 3 6532
391056 -
391057 -       2.  Java-based XML recently developed by Grzegorz Skorupa.
391058 -           Grzegorz was kind enough to put it under a FreeBSD license
391059 -           and make the source available at...
391060 -
391061 -               [On 000218 Erick reports that James Gosling developed
391062 -               Java. ref SDS 17 YD5G
391064 -               ..
391065 -              http://pikosoft.dragontiger.com/index_en.html.
391067 -            ..
391068 -           This editor works along the lines Eric envisions -- with a
391069 -           JTree for structure and a secondary pane for content. Most
391070 -           don't present what he considers a reasonable interface to
391071 -           the user. Adept being a notable, and expensive, exception.),
391072 -           ref DRT 3 5568
391074 -      ..
391075 -     It is not clear from the record if Eric includes Adept as a
391076 -     recommended base editor.
391077 -
391079 -      ..
391080 -     Extension Cord Architecture
391081 -
391082 -     Eric further relates in his second letter work by Warner Ornstine
391083 -     on an "Extension Cord Architecture" that allows new components to
391084 -     be added or replaced in an existing application. He is currently
391085 -     examining JEdit, to see if it's EditBus can work, with XML.
391086 -     ref DRT 3 1624
391088 -      ..
391089 -     JEdit is at...
391090 -
391091 -         http://www.gjt.org/~sp/jedit.html
391093 -      ..
391094 -     This work is in the formative states; it might provide the
391095 -     capability needed for a DKR system. ref DRT 3 1173
391096 -
391097 -
391098 -
391099 -
3911 -

SUBJECTS
Double Contain Comments and Code
Summary Connected to Detail

4204 -
420501 -      ..
420502 -     XML Editor Literate Style Hierrchial Programming Capabilities
420503 -
420504 -     Follow up ref SDS 9 3551, ref SDS 7 0612.
420505 -
420506 -     Eric's 3rd letter, ref DRT 4 0001, modifies earlier submission on
420507 -     detailed requirements for an editor based on XML.
420508 -
420509 -         [On 000131 Jack Park working on an XML editor. ref SDS 14
420510 -         0866]
420512 -          ..
420513 -         [On 000208 Eric asks for suggestions on what core capability
420514 -         of DKR should be. ref SDS 15 8960]
420516 -      ..
420517 -     This seems to be a detailed implementation of an XML Editor as
420518 -     core of DKR, explained in the first letter, ref SDS 0 3383, and
420519 -     providing custom capabilities described in Eric's second letter.
420520 -     ref SDS 0 3600  It supplements the design outline for the Document
420521 -     Management set out on 000125, ref SDS 9 3867, originally proposed
420522 -     on 000120. ref SDS 6 3871
420524 -           ..
420525 -          [On 000210 Eric submits detailed design requirements for OHS
420526 -          and email system, noting it is based on an XML editor.
420527 -          ref SDS 16 2993]
420529 -           ..
420530 -          [On 000305 Xanadu claims to solve limitations of XML for DKR
420531 -          hyper-document system project. ref SDS 19 1188]
420533 -           ..
420534 -          [O00505 Eric's specs for OHS includes XML. ref SDS 22 4951
420536 -      ..
420537 -     Eric does not cite the prior document, but seems to present the
420538 -     revised text under a heading "Original Message." ref DRT 4 6162
420540 -      ..
420541 -     XML is reviewed on 000125. ref SDS 9 7568
420542 -
420544 -         ..
420545 -        Summary Linked to Detail
420546 -        Double Contain Comments and Code; Collapse, Expand Hierarchy
420547 -
420548 -        For a literate style of programming in a hierarchical system,
420549 -        comments need to "double contain" both other comments and code.
420550 -
420551 -        Need ability to...
420553 -              ..
420554 -          •  collapse the hierarchy so you see only comments, and
420556 -              ..
420557 -          •  expand it at certain points to see the code tucked under
420558 -             them.
420560 -         ..
420561 -        That style produces a more readable, better documented program,
420562 -        because code that can't be collapsed into a comment sticks out
420563 -        like a sore thumb. ref DRT 4 6162
420565 -         ..
420566 -        Summarizing intelligence is essential to manage "knowledge" of
420567 -        any kind, explained in POIMS. ref OF 1 0561
420569 -         ..
420570 -        Eric proposes an Editor style sheet to manage comments.
420571 -        ref DRT 4 6675
420573 -         ..
420574 -        He discusses code management capability for comments.
420575 -        ref DRT 4 3008
420577 -         ..
420578 -        Facile handling of "data objects" seems to be a major aspect
420579 -        of Java, reported by Sun at...
420580 -
420581 -                http://java.sun.com/jdo/
420583 -         ..
420584 -        Saying in part...
420585 -
420586 -            The Java Data Objects (JDO) API is a standard
420587 -            interface-based Java model abstraction of persistence,
420588 -            developed under the auspices of the Java Community Process.
420589 -            The original JDO 1.0 is Java Specification Request 12 (JSR
420590 -            12)...
420592 -         ..
420593 -        Another source....
420594 -
420595 -            Developer.com
420596 -
420597 -              http://www.developer.com/db/article.php/1580231
420599 -         ..
420600 -        Says in part...
420601 -
420602 -            In object oriented programming, when utilizing Java, data
420603 -            is transient, meaning that it usually only resides in
420604 -            memory and will be destroyed when the application ends.  In
420605 -            developing many applications, this is a problem because a
420606 -            requirement or goal is for the data to remain persistent --
420607 -            meaning continuing to exist outside of the (single)
420608 -            application instance.  Traditional data stores such
420609 -            databases files system, sand so forth are generally used
420610 -            for persisting data.  In relational databases, data is
420611 -            stored in tables containing columns.  Relationahsips are
420612 -            created between these tables.  In Java, an object-oriented
420613 -            language, data is manipulated as objects.  Clearly defined
420614 -            relationships between Java objects and database structues
420615 -            do not exist.  As a result, progfammers must create
420616 -            relatioships between objects being utilized in their
420617 -            applications and the data stores the data actually resides
420618 -            in.  Examples of existing options for persisting data
420619 -            include JOBC, JQLJ, EJBs, and java.util.Serializable.
420620 -
420621 -
420622 -
420623 -
420624 -
420625 -
4207 -

SUBJECTS
Objectives, Collective IQ
Global Problems Too Vast Lack Focus
Mellennium Project Illustrates Problem Solving CODIAK
Version Control
CODIAK Intelligence Capabilities

4807 -
480801 -  ..
480802 - Millennium Project Illustrates Problem Solving of CODIAK, Versioning
480803 -
480804 - Follow up ref SDS 12 4028, ref SDS 11 4028.
480805 -
480806 - John reports Jerry Glenn cited the Millennium Project as a test bed of
480807 - CoDIAK.  The briefing/decision-influencing aspects and especially the
480808 - macro-level focus still leave me not enthused at all and almost
480809 - antagonistic to Millennium, but John plans to look again at their
480810 - version tracking stuff. ref DRT 1 8585
480811 -
480812 -
480813 -
480814 -
480815 -
480816 -
4809 -

SUBJECTS
Security, Privacy

4903 -
490401 -  ..
490402 - Privacy Issues Presented in Colloquium Class 4
490403 -
490404 - Follow up ref SDS 7 8398.
490405 -
490406 - John plans to review the web site...
490407 -
490409 -                   ..
490410 -                  http://www.crit.org
490411 -
490412 -
490413 - ...in the markup of David Brin's discussion on privacy. ref DRT 1 5548
490415 -  ..
490416 - On 000124 Tanya Jones set objectives for privacy, ref SDS 7 4278,
490417 - which were reviewed previously with the U.S. Army Corps of Engineers
490418 - on 981107. ref SDS 3 4494
490419 -
490420 -
490421 -
490422 -
490423 -
490424 -
490425 -
490426 -
4905 -