"Extensible Nomenclature for the Generic Exchange Language
Between Alternative Representation Taxonomies"
I actually think we almost have access to this now.
You may be overly concerned with dealing with information
in complex ways in some highly optimized encoding during some
complex processing steps. The OHS deals with information items
that are components of a hyperdocument.
This is a tough definition because for sure there is more than
Nomenclature because of its algorithmic transformation aspects.
And Taxonomy is limiting, because structural relationships
including vocabulary, perhaps even an ontology can be transformed.
And Distributed should be in there somwhere.
> "what services does an OHS provide?".
A simple one we established is to copy an item from one window
and pasting it into another, along with keeping track of the evolution of
You have great thoughts on this.
----- Original Message -----
From: "G. Ken Holman" <email@example.com>
To: "Open Hyperdocument System Development List" <firstname.lastname@example.org>
Sent: November 24, 2000 10:45 AM
Subject: Re: Ken Holman and XML
> 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
> 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
> I appreciated Nicholas' phone call yesterday where I could again share
> 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
> >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
> 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" <email@example.com>
> >To: <firstname.lastname@example.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
> 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
> 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
> 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
> 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
> 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
> definition". The communication methods between the Hyperscope and the
> 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
> developers will promote adoption and exploitation of the ideas.
> What if Oracle wanted to implement an OHS ... their services would
> 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
> 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
> ... 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
> 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
> satisfy identified needs for programmatic interfaces to the OHS. It will
> probably be necessary to reify the abstraction multiple times for
> 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
> 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
> a system without including particular concrete examples or implementations
> of the system (the running of a department store vs. Macy's). I heard
> talk about the urgent need to first develop the OHS ontology. At one
> 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,
> 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
> in some tight programming interface just to "say" it is implemented in
> 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
> 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
> 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.
> vocabularies are reified as syntax using XML lexical conventions, but they
> really represent the *information* a user of the vocabulary needs to
> ... 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
> 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
> 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
> I better get back to my work now since today isn't a holiday here. I
> 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
> 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:58 PDT