* Eugene Eric Kim <email@example.com> [000723 10:49]:
> I think a more worthwhile project would be to develop a very small XML
> DTD, perhaps a subset of XHTML or DocBook, specifically for writing
> documents that we plan on posting on the bootstrap.org web site. You
> could then write a program to add the purple numbers. From my perspective
> as an XML novice, it would be more interesting to do the conversion by
> writing an XSL stylesheet that creates HTML output with the purpose
> numbers, just to see what the corresponding XSL would look like.
> What makes this an even more worthwhile, small project, is that we can
> bootstrap on top of it, taking advantage of the knowledge gained from
> developing this, and possibly even incorporating code into the OHS.
I think we are both working toward the same goal but starting in
different places. Let me try to describe what I think a good first
goals would be and why.
This may be a little too verbose, but the ideas are here.
I see the OHS as a number of sub-projects. My understanding of the
goal is to allow linking, editing and navigation of data. Much emphasis
has been on XML representations and the client/browser/editing end.
Once data is "in" the OHS, this is definately the set of tools
necessary. But I also see the OHS as a lens through which you can see
data out on the standard WWW too. The data clearly may become much more
manageable once "imported" into the OHS or created there natively, but I
also see a need to link and view data from external sources.
My thought was that creating some kind of demo where the structure of
the OHS manipulation mechanisms would be shown -overlayed- on top of
other people's data. This may be a powerful visual demo for people
interested in the project. This is actually one of the translators that
were envisioned for perhaps later, but moving this lens to the back of
the OHS once it's more fully developed would be rather straight forward.
Another thought was that perhaps we don't need so much data in the OHS
directly. If we have a URL and a standard transformation of that data,
we could store a link to reference a paragraph within the foreign document
without the need to store it locally. This would require more link
management, but less content management.
I was reading the "Minimum Elements of an OHS" and came across paragraph
11F, The Hyperdocuemnt Library System. These thoughts would be a
partial implementation. It couldn't gaurantee the data would be
available, but anything that stays on the WWW could be accessible. It
would be development of some Back-Link capabilites.
One of the proxy servers that I was looking at, JunkBuster, has the
ability to accept requests from browsers, and I believe it can actually
do transformations on URLs. This may be a good way to pass display
commands back to another mechanism to apply a different XSL view to
similar data. This may be useful again if not long term then as a
I guess I am trying to focus on the linking and display capabilites
before attempting the UI development. I can even envision some
translators for others to view the data within the OHS again as HTML
allowing browsing and re-publishing back to the Internet. I think this
is important since not everyone will have the luxury of using an OHS
system or XML editors.
The IBM software also sounds very interesting, their Web Based
Intermediaries. The WBI is what got me started thinking about these
topics. Unfortunately if targeting OpenSource developers, since WBI is
binary only it may be of limited use. I have looked for and found some
similar OpenSource alternatives. IBM mentions an OpenSource effort of
this product, which may be exactly what we need. Doug, did you ever
have a meeting with these folks? I know it got rescheduled from last
-- -- Grant Bowman firstname.lastname@example.org -- SuSE +1-510-628-3380 x5027 -- 580 Second Street, Suite 210 fax +1-510-628-3381 -- Oakland, CA 94607 http://www.suse.com
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:47 PDT