RE: [unrev-II] OT on: [xtm-wg] historical perspective about graph s

From: Dennis E. Hamilton (
Date: Thu Mar 29 2001 - 13:38:22 PST

  • Next message: Jack Park: "[unrev-II] Fwd: Fw: Re: [PORT-L] Goguen's Semiotic Morphisms"

    Great question.

    COHERENCE - Work in Progress

    The example I *had* used for interoperability, in the late 80's, was
    international telephony. Notice that not only are there technical
    interconnection arrangements at several levels of protocol (and
    abstraction), there is nevertheless no assurance that when I make an
    international call a meaningful conversation can be held. The party says
    "Prago," I stumble around in beginning Italian until I get that they'd
    rather I send a fax that they can translate and respond to. That would be a
    good outcome for me. When in Italy last year, I used an Italian cell-phone
    and Italian service. I did great until I had to make any calls that took me
    to voice menus, as when adding more Lira to my account for pre-paid calls.
    It really got to me how we have aggrevated the system by using these
    automated systems that don't deal with the fact that the caller may not be
    able to understand the instructions and be left completely disempowered. I
    have that experience when I get into the maze of menu selections at my
    health-insurance system.

    Coherence in this context is about seamlessness and not having the
    implementation show through. That also means that a lower-level protocol
    should not be exposed at a higher level where it is intrusive and out of
    context. The messages that come with blue screens are classic in this
    regard, as are most that provide "Yes, No, Cancel" options to users, along
    with inscrutable stuff with hexadecimal numbers included. Nowhere is the
    user who encounters one of these for the first time given a clue about the
    consequences of those choices having any relevance to what they are up to
    and is important to them. (Am I going to lose my work or not, and how do I
    get out of this without my boss yelling at me?) Then think about the
    information not being in the native language of the operator.

    If you think this is too great a stretch, consider the simple matter of my
    giving you my Paris phone number, say, and you figuring out how to translate
    that into what you need to dial to get to me from, say, Menlo Park. I know
    what I need to dial to get you, and I know what I need to tell any other
    international dialer to reach me. My international telephone number where I
    am sitting this moment is +1-425-793-0283, and anyone comfortable with
    international telephony knows what they need to do to reach me from their
    system anywhere on the planet (or off). Now guess what. Lately, I have
    seen helpful American companies listing their international numbers in
    product literature in the form 011-331-55-33-0990 (a number I pulled out of
    the air, so please don't call it). I leave this as an exercise for the
    internationally-aware to tell us what the breakdown is here. (Hint, what is
    the difference between publishing an absolute URL and a relative URL in a

    For me, usability, interoperability, and coherence are different but not
    entirely orthogonal in practice.


    I first ran into "coherence" as in "Coherent Programming" at a workshop at
    Lincoln Labs around 1969. I believe Yntema (don't trust in the spelling),
    who convened the conference, introduced the term because "Modular
    Programming" had been appropriated and corrupted in the context that he was
    concerned with. Mel Conway and I went from Sperry Univac and it was very
    interesting, especially around the different places the guys with Burroughs
    operating systems were about this in comparison with the guys struggling
    with the OS/360 job-execution model and programming environments.

    In the 90's "coherence" was a theme at Xerox Corporation with regard to the
    experience and flexibility that users required for integration of office
    products seamlessly into connected systems that were also mated with the
    other systems and incorporated with work practices in the enterprise. Peter
    van Cuylenberg was a champion of that concept. It was very clear, by the
    way, that developers in the 80's thought they were done with
    interoperability if they could get a network port or serial port onto the
    machine. (I've been hunting down PvC to see what is available for public
    access on anything done on coherence during his time at Xerox.)


    When I took focus on interoperability while a senior systems architect, I
    noticed that interconnection and interoperability had been collapsed
    together by product programs. You can't interoperate without the connection
    but the connection is not sufficient, yes? There are higher level protocols
    and standards to address to accomplish integration of end-to-end systems
    into existing human systems, and that is where I saw interoperability as
    critical. My telephony example deals with the demonstration that
    interconnection and interoperability aren't the same, especially when you
    close the protocols and put the users at the end points into the picture.
    (A common design failure here is to look at the user interfaces as halves of
    protocols and be designing one-half-protocol clapping.)

    Recently (in the past 12 months), I saw people building so-called
    interoperability standards who intentionally introduced provisions where
    substitutability on either side of the interface boundary was not assured
    and was not even promised in the ideal. Implementations were given
    non-interoperable ways to introduce customizations that can and do mystify
    users and make the whole thing a mystery when the obvious is expected and
    does not occur. Yet I know that users think they are getting more than that
    and are very clear in demanding the ability to plug-and-play, make
    substitutions, and be able to grow and scale and evolve their systems of
    applications without being forced to throw a very large switch that makes an
    irreversable and global state change in the configurations. Been there,
    done that, nobody is willing to put themselves through that any more,
    especially if it means getting the mess all over their prized and hard-won
    population of loyal customers. Yet I continue to see people taking what
    were intended to be interoperability standards and neutering them into
    interconnection standards in order to achieve consensus and
    vendor-room-for-innovation-and-differentiation. And then there are ways
    that people "improve" and "innovate" around published standards after they
    are in print. I love all this stuff "based on" but improving on XML for
    special functions. There are days when I would like it to be the law that
    every other keyboard sold must be a Dvorak keyboard, and that the others be
    required to be QWERTY. Not because I think that is a great idea. I want us
    to see how ridiculous we get in this area, usually because we leave out the
    reason we have the system in the first place: serving the purposive
    activities of human enterprises.

    That is where I put in coherence. Maybe it would be better to stand for
    more integrity in alignment of "interoperability" with what the real
    customers want to accomplish with it. I am willing to fight that good
    fight, yet I need a term that is clearly not the already-corrupted one. And
    there is a clear distinction for coherence. It resonates in examples I have

    A case in point ...

    My greatest source of examples of systems incoherence these days is in
    e-mail. Now that e-mail is getting more and more sophisticated every day,
    the incoherence is startling. It happened today while I was typing this
    note. A colleague and coach in another domain of my life sent me an e-mail.
    It arrived as plain text with a bunch of attachments. The attachments had
    the default icon used by Outlook when it has no clue what the nature of the
    attachment is. They looked to me like they are Excel spreadsheets, about 7
    of them, but the file-naming doesn't have the right form. They are
    MIME-tagged as "Microsoft Excel Workbook" type, though.

    So I hadn't tried to open these until I could save the attachments to files,
    rename the files, virus check them, and then open them up and look at them.
    All stuff I am perfectly competent to do, though it meant I hadn't looked at
    them yet.

    In a phone conversation, I asked him if he was using a Macintosh or
    something. He said no, he was using Outlook (just like me), and that he'd
    taken a spreadsheet I sent him and just copied and pasted some rows that he
    wanted to include in the body of his message. From his end, it all worked
    and he saw himself sending a nice note with blocks of Excel cells pasted in
    at various places. That's not what I got, it is what he saw himself
    sending. I got a plaintext message (my preference) with some
    inscrutable-so-far attachments.

    As a self-appointed student of coherence, it was pretty easy for me to work
    this out with him over the phone. I can't wait to see if I can actually
    open these things, which are Excel clippings somehow made transportable to
    me via Microsoft OLE technology.

    Now this happened when I and the other guy were running the same software!
    If either of us were less seasoned, figuring this out would have been
    frustrating and probably unsuccessful. He would have had no clue what I was
    telling him I was getting, and I wouldn't be able to figure out from what he
    was telling me what was going on through the various layers of protocols and
    assembly-reassembly of lower-level data. I still don't know what the
    disparity is, I just know I have yet another great example of system

    On this list, you guys are going to get to wallow in this when some of the
    work on piloting of collaborative DKR/OHS/... . Using e-mail to carry new
    protocol data elements with respect to linkages and dependencies with other
    materials and other e-mails will put coherence issues in your face because
    of differences among components and end-points (and mid-points) and simple
    things like settings for user preferences.

    WOW. Thanks Jack, for giving me this great space to rant in!

    -- Dennis

    AIIM DMware Technical Coordinator
    AIIM DMware
    ODMA Support
    Dennis E. Hamilton tel. +1-425-793-0283 fax. +1-425-430-8189

    -----Original Message-----
    From: Jack Park []
    Sent: Tuesday, March 27, 2001 10:49
    Subject: Re: [unrev-II] OT on: [xtm-wg] historical perspective about
    graph s


    I would like to read more on "coherence." I think of that term in relation
    to lasar beams and such. How do you map it to what has been called

    >From my model of the universe, interoperability has two senses, one that is
    satisfied by protocols -- syntactic, mechanical interoperability, and one
    that satisfies the need to reduce or eliminate ambiguity -- semantic

    Those two imply: same socket/same XML dialect, and same page. Now,
    coherence... same direction?


    From: Dennis E. Hamilton <>

    > Much to my regret, I have learned that what computer people call
    > interoperability has been corrupted into a very weak condition. Because
    > that, another term has been introduced that strikes me as closer to what
    > unification accomplished in the sciences. It is "coherence."
    > Interoperability is extremely valuable for coherence, but it is not
    > sufficient (and might not even be necessary).
    > (Your terminology may vary. I always thought interoperability was what I
    > now have trained myself to refer to as coherence.)
    > This is a nit in the context of the point of this message. Thanks for
    > forwarding it.
    > -- Dennis

    This message is intended only for the use of the Addressee(s) and may
    contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
    the intended recipient, dissemination of this communication is prohibited.
    If you have received this communication in error, please erase all copies
    of the message and its attachments and notify

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    ------------------------ Yahoo! Groups Sponsor ---------------------~-~>
    Do you have 128-bit SSL encryption server security?
    Get VeriSign's FREE Guide, "Securing Your
    Web Site for Business." Get it now!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2b29 : Thu Mar 29 2001 - 13:48:18 PST