[Fwd: [unrev-II] Re: Need email address ... here's contact info for Peter Chen]

From: John J. Deneen (jjdeneen@ricochet.net)
Date: Sat Aug 19 2000 - 11:37:38 PDT

Re: List of specific areas where we need immediate contributions


In the XLink spec App. B, I recognized your affiliation with the
Bootstrap Alliance. So, Doug Engelbart and I are wondering if you and
possibly other experts, could contact our team leader Eugene Eric Kim
(eekim@eekim.com) about pro bono consulting support in applying XLink
and XPointer technology as indicated in Eugene's list and Eric
Armstrong's discussion below?

Our OHS development effort is now a SourceForge project
(http://sourceforge.net/projects/ohs, http://ohs.sourceforge.net).
Another evolving site is OHS ZWiki

Also, the first version of the Doug Engalbart Audio Glossary is now up.
Please have a look at http://www.liquid.org. When it's approved by you
all and Doug.

It will be time to put it on the Bootstrap site, including: A
Conversation With Doug Engelbart; Solving complex problems as a life
goal, Dr. Dobb's Journal September 2000 Bby Eugene Eric Kim.

Thank you,

John Deneen
(925) 229-1858

> Subject: focus
> Date: Fri, 18 Aug 2000 14:00:44 -0700 (PDT)
> From: Eugene Eric Kim
> Reply-To: ohs-dev@bootstrap.org
> To: ohs-dev@bootstrap.org
> ... People who want to help us progress need to do so by
> contributing in areas that we've addressed. Or, if they disagree with
> these areas, they need to make their objections known.
> With this in mind, here are list of specific areas where we need immediate
> contributions, along with what's being done in those areas right
> now. If you want to work on an area, say so. This way, at least we'll
> have a better idea of who's working on what.
> 1. Initial architecture and design for stage one: e-mail archiving.
> We've done some work here already, but we need to close it out once and
> for all. As I mentioned, Doug is meeting with several people
> individually to try to come up with a unified architecture, which we
> can then propose to the community at large. Even if you are not one of
> those people Doug is meeting with initially, you can make some
> important contributions to the design, especially by commenting on some
> of the documents that have been produced and that will be produced.
> 2. Augment->XML->HTML.
> Shinya has done an initial translator, and Grant is going to help here
> also. Hopefully, the two will start reporting on their progress on
> this list, especially so that others can start giving feedback. Once
> an initial translator is up, this will have ramifications for the item
> above, because Doug will be able to put up many of his design notes and
> documentation from years past.
> 3. E-mail DTD and Augment DTD.
> I proposed the former already, but it's nowhere close to ready for
> primetime. I'm going to go over some specs this weekend to try to
> solve some of the outstanding issues, but help is always useful. Grant
> and Shinya are ostensibly working on an Augment DTD.
> If you want to contribute to these areas, the best thing you can do is
> absorb the appropriate XML specs, especially XLink and XPointer. I
> know it would be useful for me if I had someone to kick ideas and
> questions off of regarding these technologies.
> 4. Client mockups and prototypes.
> The debate over what technologies we should assume in the clients are
> premature, in my opinion. The first step should be to mockup potential
> user interfaces. Sheldon is working on this right now, but other
> contributions would be great.
> These mockups could be in the form of images or prototypes. Based on
> feedback from Eric and others, I'm convinced that we need to mockup a
> number of clients. One absolutely needs to be web-based (HTML
> 4.0). But we also need one or more prototypes that demonstrate fancier
> functionality. These would not only demonstrate the direction the OHS
> is headed, but it may also persuade people, such as the Helix Code and
> Mozilla folks, to modify existing client software to incorporate the
> functionality of the OHS. I think Python would be a great technology
> to use for these prototypes, and I hope Paul or others can offer advice
> or contribute in these areas.
> These are all things that can be done now, as we finalize the overall
> architecture. If you're planning on contributing to the project right
> now, please either volunteer to one of these areas, or explain why some
> project should or shouldn't be included.
> -Eugene
> --
> +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
> | "Writer's block is a fancy term made up by whiners so they |
> +===== can have an excuse to drink alcohol." --Steve Martin ===========+
> Subject: DTD-processing proposal
> Date: Thu, 17 Aug 2000 20:43:49 -0700
> From: Eric Armstrong
> Reply-To: ohs-dev@bootstrap.org
> To: ohs-dev
> I just sent this proposal to the XML developers at Sun:
> -------------------------------------------
> How about an API to expose the DTD?
> A simple collection of entries would be sufficient, I think.
> -- something about as structured as a DTD is.
> One potential reason:
> * XML has no mechanism to distinguish between "structure" and
> "inline" tags.
> * That distinction makes intelligent XML editing possible.
> (See http://www.treelight.com/software/XmlEditor.html)
> * One way to attack that issue (presented in the paper) is
> to predefine the elements that are "inline" in the editor.
> * Another way that occurs to me is to establish the convention
> that all such elements are defined in a DTD-entity named
> "inline".
> The DTD could then be inspected for that definition, and tags
> contained in it treated as inline elements -- if editors could
> access the DTD easily.
> ------------------------------
> Notes:
> * It's a bit half-baked, but could be part of an OHS solution.
> * It would allow a DTD to define arbitrary new tags as
> inlinable.
> * Unfortunately, though, it wouldn't define how they should
> be displayed (as bold, or ul, or what have you).
> * It still doesn't solve the problem of having a higher
> validation standard than they typical editor understands.
> (On the other hand, any editor that *does* understand that
> validation standard could interoperate freely with the mail
> client -- and that may well be sufficient.)

attached mail follows:

John: I've had a fair amount of communication with him; he's interested in the
Bootstrap pursuit. If he's an XLink expert and could help out OHS Project, I'm
sure that he'd be willing to respond to an approach by any of our knowledgeable

Chen, Peter Pin-Shan PhD -- chen@bit.csc.lsu.edu / office (225) 388-2483 Fax:
388-1465 / voice-mail pager 800-854-5786


Missing old school friends? Find them here:

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 - 17:57:52 PDT