From: "Jack Park" <jackpark@verticalnet.com>
With regard to using XML, here is a web site that offers source code for a
Java browser that displays XML files using XLL and XSL. It is a project
built for a Masters Thesis that is also available.
My experience with it says it has a few bugs that are easily fixed.
http://pages.wooster.edu/ludwigj/xml/index.html
Given this class of browser, it becomes possible to use an XML editor along
the lines suggested earlier by Eric, and paint the ongoing document in a
browser as a non-editable wyswyg display. I am building such a tool as a
literate programming front end for my program The Scholar's Companion(r).
Editing special objects (e.g. concept maps, frames, etc) is done in separate
dialogs and the resulting XML appended to the ongoing text display in the
XML editor itself. Inserts, deletes, and so forth are handled in the dom
tree to the left of the text display. Large issues appear to center, at
least for me, on the blending of the literate programming code with the rest
of the XML handlers.
A useful link for literate programming has been
http://www.loria.fr/services/tex/english/litte.html
With regard to using dom, implementations to date have all been
memory-resident, which poses a problem with enormous documents. I have not
found an open-source implementation of a virtual dom system, though such an
implementation does exist in a product.
Appropriate thought needs to be given to the issues that arise from the
generation of documents that are not necessarily hierarchical in structure.
RDF, and Groves might offer a more general representation scheme. There is
some information on using RDF and XSL at
http://www.cee.hw.ac.uk/~alison/mirador/xml/demo.html
A really useful Java project is the xml testbed at
http://www.w3.org/XML/1998/08withall/
It is not strictly open source: you cannot use it in commercial products
without permission, but it can be used and it includes perhaps the only
implementation of Groves that I have found thus far.
Jack
> 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:
> 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
--------------------------- 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:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:42 PDT