1200 Dale Avenue #100
Mountain View, CA 94040
Date: Mon, 13 Nov 2000 14:05:59 -0800
Preliminary Meeting with Ken Holman
Several of us had a chance to meet with Ken Holman over the weekend. He was
brought to the party by John Deneen, and he was quite happy to meet Doug. He
very much wants to make whatever contribution he can, which pretty much makes
him "one of the team".
Ken is very knowledgable about XML and related disciplines. And he is, or has
been, very active at OASIS (Organization for the Advancement of Structured
Information Standards). He is looking forward to helping us define an
interchange standard, and shepard it through the various committees, and so on.
He also has a remarkable flair for design. He picked up a rough sense of what
we were about in fairly short order, and began making insightful observations
based on his past design experience.
Here are some of the technical points he developed during the meeting...
- Most application designs define an application-specific
language, and parse that. They tend
to consider XSLT as an afterthought. To make
use of it, a different representatiion is
parsed, written out as XML, and then reparsed
into the app.
- But XSLT can quite easily produce SAX or
DOM output *directly*. So the kind of design
Ken recommends, uses XSL and a style sheet
to process any particular XML data. The result
becomes SAX events or a DOM in the app, so
that part of the app doesn't change. But now
you can process any other variant of the
XML that encodes the information, simply by
creating a new stylesheet, without a big
peformance hit -- the result is roughly
equivalent to having defined that language (or
any other variant) as the "reference langauge"
for the application.
- Ken declared emphatically that DEFINING THE XML
EARLY ON IS INAPPROPRIATE. He's seen the mistake
made dozens of times, and counsels his clients
against it. His take on the matter is that XML
IS AN INTERCHANGE STANDARD and that the core of
the application is the services it provides.
Therefore, the only sequence that works in the
real world is to define those services, and *then*
come up with an XML form for the data that needs
to be interchanged.
- In terms of the OHS, Ken's approach had some remarkable implications for
the design. Rather than attempting to define a DTD for a "normal form" OHS
document, Ken suggests focusing on the services, and building (or at least
desiging) those services. So for example, we need granular addressibility.
And we want it to apply to legacy documents. Ok, then, the system requires
mechanisms for adding addresses to a legacy document! The orginal document
continues its existence, unchanged. The OHS contains a pointer to it,
along with a collection of addresses that point into it. The
"HyperDocument" you view in the "HyperScope" is then the product of those
addresses applied to that document.
- Note that we have *not* defined a DTD for a HyperDocument. We have
defined functionality. Now, when it comes to interchange data, how does
that happen? Well, what do you need to send? You need to send a pointer to
the original document, at a minimum -- or possibly the document itself if
it is inaccessible. And you need to send the additional information (like
the addresses) that are necessary to carry out HyperScope functions!
- Ken's point here, is that XML definition is dictated by functional needs
-- by what you need to transmit to provide the desired services, and the
resulting XML definition is far removed from any sort of "HyperDocument
definition" we may construct at the outset.
[Note: From personal experience, I concur wholeheartedly. The
orginal stab I took at XML syntax for such a document looks nothing like
the node library I am currently constructing. More instructively, none of
the last 4 versions of that library look very much like any of the
Ken also talked about topic maps for a bit. (Although I have yet to "get" them,
Ken was very big on them, and mentioned Jack Park's advocacy several times in
What I gleaned from our short forays into the
- Topic maps provide a way of defining the
semantic content of a structure or, perhaps
more accurately, it is a way of specifying the
syntax that is used to represent different
semantic constructs. (I believe that is
accurate, although I didn't quite get how
More info: More info: http://www.topicmaps.org
- Ken suspects we want to use topic maps to
define the OHS interchange mechansims.
(Again, I don't see how that works, exactly,
but I suspect that he and Jack will be
able to arrive at a meeting of the minds.)
- My one little "aha" on the subject is that
if XSLT + a stylesheet can be used as the
input to an application, then if the input
is defined using a topic map, then anyone
can use any syntax they want to encode the
data -- the syntax will be transformed by
XSLT for use by the application anyway, and
that translation will be governed by the
topic map. (I think that is somewhere
within a Silicon-valley commute of being
<! copy >