Loading ...
Sorry, an error occurred while loading the content.

Re: [xml-doc] Efficient search strategies

Expand Messages
  • mpriestl@ca.ibm.com
    ... Wow. No offense, but you don t know what you re talking about. First off: - at IBM, we ve been doing singlesourcing for years with SGML - the XML strategy
    Message 1 of 7 , Oct 1, 2002
      Tim Harvey writes:

      >If you doubt this, consider IBM's (and many other
      >companies) rejection of the previous "next big thing"
      >- SGML - in favor of the current "next big thing" -
      >XML and single-sourcing. The challenge for
      >communication professionals employed by IBM, now swept
      >up in this "new break through technology," is how to
      >curb their "creativity" (read that "professional
      >judgement") so their work conforms to the narrow
      >demands of fully realized XML.

      Wow. No offense, but you don't know what you're talking about.

      First off:
      - at IBM, we've been doing singlesourcing for years with SGML
      - the XML strategy is designed to incorporate advances in information
      design we've made since then
      - and also make it possible to accomodate both centralized infrastructure
      and audience-focussed information, through a new mechanism call
      - "the challenge for communication professionals employed by IBM" was to
      come up with an architecture for accomplishing more efficiently what we
      were already doing in a variety of ways at higher cost
      - and that's what we did

      Second off, the use of XML in IBM for technical documentation was an
      initiative of the technical communications community, and the resulting
      architecture (DITA) designed by a workgroup with representation from
      technical communication groups across the company and its subsidiaries. I'm
      one of its architects, and I've been a full-time information developer for
      nearly a decade; that was my major qualification for involvement with the
      project. My XML developer certification was secondary.

      >Technical communication professionals are now urged to
      >set aside their previous concern with audience to
      >write "information components" in a neutral voice.

      No they aren't. You might notice that every topic in a DITA architecture
      has metadata for identifying the audience, their task, and their experience
      level with that task; and nearly every element has an audience attribute as
      well, to determine within-topic differences. Topics should be developed
      from a task analysis that includes an audience analysis. The fact that 1)
      multiple information sets share the same audience and 2) multiple audiences
      share the documentation, should be obvious - this does not require the
      abandonment of an audience focus, but an accomodation of the actual
      complexities involved in identifying and serving multiple audience needs.

      >They are told that the evolutionary step up made
      >possible by XML requires this because information
      >modules can be expected to "go anywhere" ("repurposed"
      >many times as information "building blocks"), and that
      >good knowledge design is superior to writing that
      >actively engages audiences.

      No they aren't. They are told to avoid designing to media constraints.
      That's kinda the point of XML. They are told to actively pursue designing
      to knowledge and audience constraints. That's kinda the point of DITA.

      Your reading in this area has led you astray, perhaps because you
      approached it with an agenda in-hand.

      >"People do not want to
      >read" they are told, "they just want to get
      >information quickly, as they need it."

      OK, this they are told: task and reference information typically involves
      addressing a mid-task failure. Very, very few people read a User's Guide
      end-to-end; absolutely nobody reads a help system end-to-end. Assuming that
      someone has read a "previous" topic, when most of the time they got to the
      topic via search or index, is bad. Very bad. That doesn't mean all
      information fits in that bucket, just 90% of what users read. For
      scenarios, tutorials, getting-started information, etc - topics may be part
      of the solution but they certainly aren't sufficient in themselves.

      >Where are the professionals evaluating and commenting
      >on the demands and impact of the XML-driven
      >single-source paradign, as outlined by the vendors,
      >consultants and kingdom builders, on the profession?

      I already told you, but you're busy ignoring me.

      >I know knowledge designers and consultants will tell
      >you that they can "vastly improve information and its
      >delivery and access," if only everyone will submit to
      >the requirements of "centralized, XML-based content
      >management systems" (and you don't rigoriously
      >quantify and test their claims). But, how do these
      >restrictions, such as writing relatively short,
      >voiceless "information components" as gist for the XML
      >mill jibe with the claim of those in the profession
      >that they and their profession have something
      >important and unique to contribute?

      - information architects are people too
      - the division in role between those who identify chunks and cross-chunk
      relations and those who write them has been part of the online information
      community since before the dawn of the web
      - knowing content and expressing it clearly is as important at the topic
      scope as it is at the "book" scope
      - in other words, it's the same-old same-old; it's just easier to do when
      technology supports your goals instead of prescribing them

      Given that I, and many like me, have been doing this for nearly a decade
      (and I do mean: singlesourcing with topic-oriented chunks), your concern
      about its impact on the profession is both tardy and overstated.

      Michael Priestley
      Program Chair, SIGDOC 2002
      DITA Specialization Architect
      Dept 833 IBM Canada t/l: 969-3233 phone: 905-413-3233
      Toronto Information Development
    • Dave Pawson
      ... Shit you do go on Tim. For goodness sake sit back, read the list and enjoy. Stop being so bloody earnest. DaveP.
      Message 2 of 7 , Oct 1, 2002
        At 19:13 30/09/2002, Tim Harvey wrote:

        >Until those kinds of questions are asked,

        Shit you do go on Tim.

        For goodness sake sit back, read the
        list and enjoy. Stop being so bloody earnest.

      • Deborah Aleyne Lapeyre
        ... Gosh, and here I ve been feeling liberated. --dal -- ====================================================================== Deborah Aleyne Lapeyre
        Message 3 of 7 , Oct 10, 2002
          and I quote:

          > "narrow demands of fully realized XML."

          Gosh, and here I've been feeling liberated.

          Deborah Aleyne Lapeyre mailto:dalapeyre@...
          Mulberry Technologies, Inc. http://www.mulberrytech.com
          17 West Jefferson Street Direct Phone: 301/315-9633
          Suite 207 Phone: 301/315-9631
          Rockville, MD 20850 Fax: 301/315-8285
          Mulberry Technologies: A Consultancy Specializing in SGML and XML
        Your message has been successfully submitted and would be delivered to recipients shortly.