Memorandum

Date: Sun, 30 Jan 2000 22:20:57 -0800

From:	Eric Armstrong
	eric.armstrong@eng.sun.com Reply-To: unrev-II@onelist.com

To:	unrev-II@onelist.com"

Subject:

DKR Prototype #1: Design Questions

Since we have not reached an agreement to try an IBIS-style discussion (nor created a separate mailing list to do so), I'll post the following questions in psuedo-IBIS form. [Note: "R" is reference. I left that out of the original discussion.]

Q: What data format should we use?

      A: XML.

           P: HTML to XML parsers already exist,
               so getting XML into the system will
               be feasible.

               R: One is promised to Apache by Sun

           P: XML to HTML stylesheets and servers
               already exist.

               R: Xalan system at Apache
               R: Servlet posted at xml-interest@java.sun.com

           P: Maintaining source code in XML is feasible

                R: [Discussion to be provided]

           P: XML-to-Augment translator is feasible

               R: JavaWorld article discussing XML front
                   ends to databases:

http://www.javaworld.com/javaworld/jw-01-2000/jw-01-dbxml.html

Q: What archive mechanism should we use?

     A: Plain files on a server
     A: Object database
     A: Relational database

Q: Will email be encoded in XML, as well?

     A: Yes

          CH: How?

     A. No

          P: There aren't any xml-email clients
          P: We won't have to write one
 
Q: How should email-announcements of changes be made?

      A: Send notices to a "registered interest" list from the
          editor when changes have been made.

      A: None. Let the server do it.

           XP: Do a TreeDiff of the document, send an
               an email announcing the changes, and
               point to a diff

           P: Easier to use a different editor

           P: Can "publish" by making announcement

               XP: Can publish once after multiple edits,
                   instead of once for every edit.

           C: No mechanism to track ongoing changes

               XP: The "publish" mechanism is great for
                   the "interest" list, but collaborators
                   may be better served with ongoing
                   updates.


Q: How will editing conflicts be prevented?

     A: Locks on files
     A. Locks on information nodes
     A. "Competing Versions" in a distributed system


Q: How should we handle responses to a node that gets deleted?

     A: Keep phantom nodes to display them under.

     A: Move them to the end of the document, like
        the CritLink, CritMail system.

Q: How will nodes be managed in the system?

     A: With a tree-management library that contains
        a pointer to an arbitrary object.

          Q: Do any libraries exist for this?

               A: I have one.

                   P: It's very flexible.

                       XP: It implements every conceivable tree
                           editing operation there is.

                   C: It needs to be modified to use Java
                      collections for performance and simplicity.

     A. In nodes that contain open-ended lists of
        subcontainers and properties.

     A. In fixed nodes.

     A. In a DOM

          P: It's designed for document management.

          Q: But will it do what we need?

Q: What's the best way to read the XML data into memory?

      A: XML data binding

           P: It will be fast

           C: It's not ready yet

      A: DOM

           P: Natural.

                XP: If we use a DOM representation.
      A. SAX

           P: Faster

           P. Flexible

               XP: If we build our own tree, this will be
                   an efficient mechanism to do it.


Q: What should we call this project?

      (If you read this far, you get a vote.)

     A: NextStep

         C: That one was taken, too bad.

     A: KR1 (Knowledge Repository #1)

     A: Cheyer's Slayer

     A. Cheyer's Prayer

:_)