Crane Softwrights Ltd.
Box 266, Kars,
Ontario CANADA K0A-2E0
+1(613)489-0999



G. Ken Holman gkholman@CraneSoftwrights.com http://www.CraneSoftwrights.com/m/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.


Date: Fri, 24 Nov 2000 13:45:21 -0500


From:   G. Ken Holman
gkholman@cranesoftwrights.com
Reply-To: ohs-dev@bootstrap.org

To:     Open Hyperdocument System Development List
ohs-dev@bootstrap.org

Subject:   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 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. Carroll, ncarroll@inreach.com
ohs-dev@bootstrap.org

November 24, 2000 12:30 AM

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.

Sincerely,

Crane Softwrights Ltd.



G. Ken Holman
gkholman@CraneSoftwrights.com
http://www.CraneSoftwrights.com/m/
Box 266, Kars,
Ontario CANADA K0A-2E0
+1(613)489-0999
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,