All,
Well, I'm finally getting the chance to post some comments. I'll start with my
two cents on the OHS Framework document and follow up on the Comparison
Categories in a separate posting.
The bottom line is that I think it's a very well thought-out spec. I haven't
been following what's been happening in the world of document architecture
since the early days of OpenDoc and OLE 2.0, but this spec is for a document of
much greater capability than either of those (which is good).
I wouldn't know about the new XML (eXtensible Markup Language) spec that Bill
D. posted - I didn't have time to decipher the referenced documents. But
markup languages in general are just providing lower-level machinery for (i.e.
allowing for - or not) the functionality you're specifying in the OHS spec.
It's not clear that embedding all of the meta information about the document
*in* the document itself is required (real hypertext systems don't :-) Anyway,
it is a design choice for representing/storing the document. I see markup
languages more as a repackaging facility for sharing a document with someone
outside of your OHS system (which usually means dumbing it down). So I see it
coming into play for interoperability with external systems. But it should be
looked at.
I have just a few architectural comments.
2A1B Mixed Object Documents
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1B1> - Unify the concept
of "document" and "object". Instead of a document as a distinct and somewhat
special-case thing (just a collection of objects, with a few of it's own
special case operations), allow the document to be an object itself, with all
object operations (for viewing, linking-to, filing, etc.) available for it
symmetrically. The main thing this does is allow for recursive scaling of
documents-within-documents as desired. View control and storage conventions
(perhaps Journaling) connote what are the top-level objects (coherent authored
packages) which correspond to what we historically think of as documents. This
allows for more modular authored chunks of reusable "knowledge", which I think
would play better in the CODIAK infosoup.
2B2A Basic Hyper Characteristics
<http://www.bootstrap.org/alliance/alliance-980.htm#2B2A1> - I thought the
basic hyperlink capability was great. I'd add that the author should be able
to specify that the link is either (a) visible as a link (a pointer that the
user can follow-to or bring-from (which you've already spec'd)) or (b) is
already bringing-from (transcluding the pointed-to data into the current
document). View controls can override, or in general allow users to see it
whichever way they'd like.
2B3A View Control <http://www.bootstrap.org/alliance/alliance-980.htm#2B3A2> -
Has the above view-control capability implied but not spelled out explicitly.
This is also where links might be made human-readable as desired? I like the
reference to allowing for Augment style "sequence generators" to be engaged
which provide alternative portrayal of a document's structure/content. There's
a *lot* implied in this paragraph that might be missed by the average designer
or product evaluator :-) but I don't know how you can say all that you need to,
without the spec ballooning. (Says we need a lower level spec someday that
traces back up to this level? Or just add detail in-place at a lower level of
the outline?).
2A1D and 2A1E time stamps and signatures - are important capabilities.
<http://www.bootstrap.org/alliance/alliance-980.htm#2A1D> I see them as
special cases of a general object "tag" facility. The author should be able to
add attribute-value pairs to any owned object (like: [relevance 1.0]
[importance 10] [discussion ohs-talk], etc.). Ideally, users would be able to
add their own private tags to any object (just as they should be able to add
their own private links from any region in any object). Some set of these tags
would be system-maintained, like the time-stamp and signature.
2B3A - more view control.
<http://www.bootstrap.org/alliance/alliance-980.htm#2B3A2> The payoff of the
above tags (besides for basic retrieval) is in viewing: for filtering-in and
filtering-out objects from the current view, and creating organizations of
objects on-the-fly. It's also the cornerstone of some
information-visualization capabilities that can be used for e.g. timeline or
scatter plotting of large collections of objects. (See
<http://www.spotfire.com/> (though this particular site is currently giving my
Navigator browser fits...)
2D End-User Systems - I think this is great.
<http://www.bootstrap.org/alliance/alliance-980.htm#2D> This gets to the
end-to-end wholes of the preceding functional parts. It's a task-oriented
touchstone for ensuring that everything hangs together as a usable system. The
web plus MIME e-mail together touch on, or are close misses to, a lot of your
OHS requirements, but these tasks show its shortcomings in short order... Some
areas could use more words just for clarification (for the average
designer/evaluator)
2D4 Online Publishing <http://www.bootstrap.org/alliance/alliance-980.htm#2D4A>
- Speaks of tracking changes to a document. I think that per-object change
detection and (requested) notification are important capabilities. It could be
implemented on top of per-user system-maintained time-stamp tags (last-modified
time by any author, vs last-read time by this user). Also falls under 2A1C
capabilities <http://www.bootstrap.org/alliance/alliance-980.htm#2A1C1>.
Well, that's it for now.
Cheerio,
John
This archive was generated by hypermail 2b29 : Thu Jan 06 2000 - 11:01:17 PST