[unrev-II] DKR Prototype #1: Design Questions

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Sun Jan 30 2000 - 22:20:57 PST

From: Eric Armstrong <eric.armstrong@eng.sun.com>

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:

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

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
      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


--------------------------- ONElist Sponsor ----------------------------

GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
Intro APR and no hidden fees. Apply NOW.
<a href=" http://clickme.onelist.com/ad/NextcardCreativeCL ">Click Here</a>


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 2.0.0 : Tue Aug 21 2001 - 18:56:41 PDT