Good day, folks,
Given how quiet the phones and business in general are these days with
those of you in the U.S. recovering from your turkey attacks of yesterday,
I finally have a few moments to capture a few comments I have. I do
apologize to everyone (as I did to Doug, John, Eric, Eugene and the others
last week) that my time is so very occupied so long ahead that it is
difficult for me to make the time right now to contribute as I wish. I
have a short conference bio at
<http://www.CraneSoftwrights.com/bio/gkholman.htm> if you want to learn
more about my background ... these days I am swamped with training that has
supplanted my consulting ... I am trying to distinguish myself from my
peers by focusing on downstream information processing and transformation
(exploiting structured information that has already been captured/authored).
I appreciated Nicholas' phone call yesterday where I could again share some
of my thoughts and how the meetings at Doug's progressed. I thought it
would be constructive to share these all of you as I would like to clarify
one connotation that he attributed to me.
I also apologize if this sounds like I'm standing on a soapbox. I feel it
is very important to help people understand that XML is not a panacea and
XML-related recommendations have distinct roles and give us valuable tools
for certain things.
One last prelude is that I am only learning about OHS "on the run" from
what was described to me at Doug's ... I apologize in advance if I
misrepresent any of your established ideas or concepts due to my ignorance
of your accomplishments to date.
At 00/11/24 06:53 -0800, Joe D Willliams wrote:
>If pseudo-code is XSL, Schema, and related XML, then I agree!
>When coding is required, then let's help develop ECMAScript and/or
>XMLScript.
>When the scripts are solid, then Java/Java3D.
Actually, that wasn't what I was saying, Joe, and if you'll bear with me I
will try to convey my thoughts as I expressed them at Doug's. I hope to
convince you to look at an approach differently.
As I understand and express what was presented to me, the early
expectations in the project for XML were to utilize this technology as a
core "independent" storage mechanism in a classical "hub and spoke"
architecture where its use would be mandated as the target transformation
format for the importation of external documents and internally synthesized
information. Somehow an OHS XML vocabulary would be developed for the
collection and maintenance of information in the system.
I truly think this is an inappropriate application of the technology.
>----- Original Message -----
>From: "N. C a r r o l l" <ncarroll@inreach.com>
>To: <ohs-dev@bootstrap.org>
>Sent: November 24, 2000 12:30 AM
>Subject: Ken Holman and XML
>
>
> > Spoke to Ken Holman today.
> >
> > Was glad to hear that -- in his view --
> > XML is the glue, not the construct.
Yes, indeed ... XML is an excellent technology to apply to the problem of
*interchanging* information between possibly (though not necessarily)
disparate stand-alone systems, or even subsystems within a larger
system. The systems could be from different vendors, from different users,
or even two systems used by a given user over a period of time such that
the systems are incompatible (thus exploiting XML for archiving).
XML is a syntactic expression technology ... it isn't designed as an active
storage technology, or an internal representation technology.
> > If I got his drift correctly, it was:
> >
> > More pseudo-code.
> >
> > Less hard code.
While hard code is definitely required to reify the results of our labours,
I am trying to convey the need for a definition of what needs to be done,
not how it is accomplished. I think thinking about XML syntax is *not*
needed at this point and applying it will be a necessary process down the
road to address certain requirements ... but not yet.
So, since I wholeheartedly believe focusing on XML isn't appropriate at
this stage of OHS development, I shared at Doug's two meetings what I think
should be done.
At the first meeting I tried to convey the utility of viewing the OHS at
this early juncture as an abstraction. Not "how do we build the OHS?" but
"what services does an OHS provide?". This is more abstract to me than
pseudo-code, Nicholas, which is a word that I never used in our discussion
yesterday. To me, pseudo-code is still too low level, but I can see how
someone else might perceive pseudo-code as an acceptable abstraction. I
would term what I'm describing as "services definition".
As Eric so succinctly minuted, I misunderstood that the Hyperscope was the
"user agent" of the system and the OHS was the services/repository "back
end" of the system. Having since heard the DKR (Dynamic Knowledge
Repository?) acronym, I suppose that could be the back end and the OHS be
the label of the entire system. But if you will allow me to again use some
of these terms below, this was how I presented it at the time.
I thought the user interacts with the OHS through the Hyperscope. The
Hyperscope is the user agent that marshals user requests and feedback to
and from the back end of the system. All the requests and feedback would
be described as a well-defined set of services and responses: the "services
definition". The communication methods between the Hyperscope and the back
end would depend on where and how the particular implementation of the
system was built. A given Hyperscope might interact with two different
back ends, implemented in two different ways, based on the connectivity
provided the user in the environment in which the user works.
It's the services that matter! Not the implementation of the services.
By not mandating any implementation constraints (and yes they will be
perceived as constraints if you tell people how they have to implement
something), then innovation and implementation differentiation available to
developers will promote adoption and exploitation of the ideas.
What if Oracle wanted to implement an OHS ... their services would probably
be supported on a relational database back end. What if Sun wanted to
implement an OHS ... their services would probably be supported across a
network of servers. What if Eric actually found the time he wants to apply
to this project ... his services could be implemented in any way he sees
fit (and make any changes down the road he sees fit) without impacting on
the definition of the services being supported.
If you can describe the OHS entirely by the services that must be provided
and the external interactions that must be supported, the system can grow
to meet the needs as they change and evolve.
I've seen this done through abstract interface definition languages
(IDL). Lots of brace brackets surrounding the descriptions of facets of
objects and services that (a) are obliged to be supported by an
implementation and (b) can be expected to be supported by a
user. Unfortunately, I'm not trained in which IDL definitions are the best
... I've just seen them successfully used. And it has changed the way I
look at problems ... getting away from the "how" and concentrating on the
"what". The "what" is what is important, the "how" is a necessary burden
to actually reify the "what", but it isn't central and shouldn't even be
germane.
The abstraction is reified as many ways as are necessary to deploy the
functionality in as many environments as possible, garnering the interest
of as many implementations as possible. It will probably be necessary to
reify the abstraction multiple times for different programming languages to
satisfy identified needs for programmatic interfaces to the OHS. It will
probably be necessary to reify the abstraction multiple times for different
platforms.
But I believe that abstractions are inherently scalable! Start with an
abstraction of a very simple task, get an implementation reified, deploy
it, learn from it, build upon the abstraction with new services. If an
implementation has to change to support the new services, the abstraction
itself hasn't been broken. If by innovation a particular implementation
doesn't need to change, all the better for that developer, but the system
design hasn't imposed restrictions on how a developer implements the
abstraction.
Then came the meeting Tuesday where Jack and Howard attended. I met Jack
first in June in Paris at a Topic Maps organizational meeting (I'm trying
to keep involved in that XML arena as well).
I learned from Howard that an ontology is a description of the processes of
a system without including particular concrete examples or implementations
of the system (the running of a department store vs. Macy's). I heard Jack
talk about the urgent need to first develop the OHS ontology. At one point
Jack mentioned about the IDL of the ontology.
This was the "a-ha!" for me ... this was where I realized that what I call
a "services definition" is what Jack calls an "ontology" ... BINGO! ...
yes, it seems I have agreed with Jack all along that we need to define the
OHS ontology, I just wasn't using the same words that he was
using. Perhaps there are ontological description languages out there, that
can be viewed simply as service interface description languages, that will
satisfy everyone's needs for describing the OHS in an inherently powerful
and flexible and extensible fashion.
That's what I think should be the focus right now.
So where can XML eventually be applied?
Possibly in the interface between the Hyperscope and the back end, where
this interface is over HTTP or a network of some kind ... but certainly not
in some tight programming interface just to "say" it is implemented in XML.
Certainly in the interface between two implementations of the back end
where information has to be conveyed for use elsewhere, but certainly not
mandated *within* any one implementation as a storage mechanism. A vendor
may, indeed, choose to do so, but that would not be under the purview of
system design. Many industries mandate interchange vocabularies in XML but
never mandate how stakeholders who do the interchange maintain their
information within their own organizations.
Perhaps development of the OHS will paint the needs for a standardized
"collaboration environment markup language" named after a lengthy
multi-syllable acronymic mouthful such as the "Extensible Nomenclature for
the Generic Exchange Language Between Alternative Representation
Taxonomies" (sorry ... couldn't resist the temptation ... needs more work)
for interchanging information between implementations of the OHS or between
an OHS and other collaboration tools in the industry. Moreover, a
technical committee could be formed at OASIS (The Organization for the
Advancement of Structured Information Standards
<http://www.oasis-open.org/committees/index.shtml> ... I am currently
chairing <http://www.oasis-open.org/committees/xslt/index.html> and
participated in the development of the generic committee process) to
standardize this as an industry-wide interchange vocabulary.
What about the other members of the XML Family of Recommendations?
The XLink, XPointer, XML Topic Maps, and many other XML-related
recommendations and conventions describe vocabularies for semantics of
information technology as identified by their respective developers. These
vocabularies are reified as syntax using XML lexical conventions, but they
really represent the *information* a user of the vocabulary needs to convey
... the semantics of what they need represented. We need to understand
these semantics and their roles in the OHS so we can build into the
services definition/ontology of the OHS the utility of these
already-defined semantics ... when it then comes time to interchange these
OHS semantics, the established vocabularies will already be there ready for
us to take advantage of in standardized syntax, and there will already be
vendor support implementing these semantics that others can exploit with
little or no modification.
I am sure we will learn a lot from the XML Family to incorporate important
concepts in the description of the OHS.
I am sure we will find a lot of possible places to deploy XML in the
interchange of information between components of the OHS or implementations
of the OHS.
From what I understand of your requirements, however, I see no need to
*mandate* the use of XML syntax internally or to decide yet on any kind of
finalized syntax.
I hope this is seen as constructive and helpful, and not critical. I look
forward to finding a role to play as a member of the team, and I have
invited John and Doug to send me small projects (document reviews, etc.)
where I might be able to give some feedback while I am otherwise so very
occupied.
I better get back to my work now since today isn't a holiday here. I would
be pleased to follow up on the list any discussion of what I've said above
... but since I've responded now to Nicolas' post, we should probably start
new threads with specific subjects to help manage the discussion.
Thank you for your patience with this tome.
..................... Ken
-- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995) Web site: XSL/XML/DSSSL/SGML services, training, libraries, products. Book: Practical Transformation Using XSLT and XPath ISBN1-894049-05-5 Article: What is XSLT? http://www.xml.com/pub/2000/08/holman Next public instructor-led training: 2000-12-03/04,2001-01-27, - 2001-02-21,2001-02-27/03-01,2001-03-05/07,2001-03-26,2001-04-06/07
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:57 PDT