OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  What Is A Topic

    Posted 12-20-2006 23:01
    I'm really struggling with the issue of what is and isn't a topic (or 
    rather, what should and shouldn't be a topic). This is partly a side 
    effect of trying to answer the question of whether or not section w/in 
    topic body should nest and partly a side effect of trying to decide how 
    best to map a client's legacy documents to topics.
    
    In particular, I'm struck by the apparent conflict between these two 
    statements from the architectural specification:
    
     From What are Topics?:
    
    "A topic is a unit of information with a title and content, short enough 
    to be specific to a single subject or answer a single question, but long 
    enough to make sense on its own and be authored as a unit."
    
    And from "Transitional Text Workarounds":
    
    "A DITA topic can be as minimal as just a title,...."
    
    Which is certainly true by the current DTDs.
    
    But this strikes me as odd, namely a topic that consists of only a title 
    cannot possibly satisfy the requirement that it "make sense on its own".
    
    Likewise, the initial definition of topic says "title *and* content" (my 
    emphasis) which certainly seems to require that topics have content.
    
    Certainly within a map it makes sense to be able to have a topichead 
    that is just a hierarchical level with a title but no direct 
    content--this happens all the time in docs [whether or not it's good 
    editorial practice is a separate question] but it seems to me to be 
    diluting meaning of "topic" to allow or condone topics that consist of 
    only titles.
    
    But clearly there is a body of either thought or practice, at least 
    within IBM, that considers a topic that is just a title to be OK.
    
    To my mind, it seems that DITA is best served by taking a fairly strict 
    view of what is and is not a topic and I focus in particular on the 
    "make sense on its own" aspect of topics, as given in the initial 
    definition of "topic".
    
    By the same token, it seems to me that if you are willing to allow 
    topics to be as small as possible (i.e., 


  • 2.  Re: [dita] What Is A Topic

    Posted 12-21-2006 00:31
      |   view attached

    Attachment(s)

    vcf
    scott.hudson.vcf   334 B 1 version


  • 3.  RE: [dita] What Is A Topic

    Posted 12-21-2006 15:43
    I don't disagree with Eliot and Scott that the wording about
    topics could perhaps be clarified a bit, though I consider
    that mostly editorial and not a substantive issue in the spec.
    
    I don't have much of an opinion about title-only topics or such.
    It's difficult for the DTD to enforce good practice anyway, and
    no matter how hard you try, a determined user will figure out
    how to do something they probably shouldn't do.  (Your bullet,
    your gun, your foot.)
    
    I will say, though, that I have less sympathy with the legacy
    conversion issue.  DTDs in general--and whole technologies like
    DITA in particular--are designed to be optimized for a specific
    set of requirements and expectations.  If a square peg doesn't 
    fit into a round hole, you don't mess up the hole, you do something
    about your peg or you look for something with square holes.
    
    I don't know if DITA sections should be nestable (some in-house
    Arbortext users did ask for this too, but again, I think they
    were trying to figure out how to map DocBook into DITA), but I'm
    pretty sure I don't want to be driving DITA design by considerations
    of legacy conversion.
    
    If you've got stuff tagged using another tag set/DTD, my first
    question is why retag it?  What's wrong with the way it is now?
    
    If there are really good reasons why it is actually worth the
    effort to retag it using DITA, then by definition, there should
    be good reasons to *rewrite* it in a topic oriented fashion rather
    than trying to cram non-DITA-isms into the DITA mold.
    
    Perhaps I'm over-reacting to the word "legacy", but I think we
    need to consider extensions to DITA in light of actual topic
    oriented related requirements rather than conversion issues.
    
    paul
    
    > 


  • 4.  RE: [dita] What Is A Topic

    Posted 12-21-2006 16:19

    I agree with Paul generally, although I also think that legacy docs can be migrated into DITA using nested topics, although at the cost of best practices. IE, you can't make legacy docs topic-oriented automatically, but you can typically fit them into a topic-oriented doctype if you want to migrate first and rewrite later.

    On the issue of title-only topics in particular I wanted to add a few things:

    - a small topic may legitimately need only a title and short description - our own glossentry specialization comes to mind. Some forms of context-sensitive help are also likely to be very short, and with the addition of abstract, easily accomodated without the <body> element.

    - a topic may start small and grow over time into a whole branch of topics. The container topic may be no more than a title and child links (or just a title, with child links managed via a map). But the container topic is still important as a link destination, because it still answers the question it originally answered when it was just a leaf-node topic.  People who link to the topic shouldn't be forced to recode or break their links just because the topic has changed from leaf node to container node. In terms of its subject, it's still the same topic.

    - this is the point at which "makes sense on its own" becomes clearly exposed as more of a guideline than an absolute requirement. Just as you might want to bend that rule to fit legacy docs, you might also want to bend it for container topics (sometimes they have enough content to stand on their own, sometimes they're the container for generated summaries of other content, sometimes they're just a navigation hub to other resources). The important thing is that the topic title is still an accurate reflection of the destination.

    I'd support adding some softening words to the topic-oriented section if that would resolve the current conflict.

    Current wording:
    >>>
    A topic is a unit of information with a title and content, short enough to be specific to a single subject or answer a single question, but long enough to make sense on its own and be authored as a unit.
    >>>

    Proposed softening:
    >>>
    A topic is a unit of information typically consisting of a title and content, short enough to be specific to a single subject or answer a single question, but long enough to make sense and be authored as a unit, often on its own.
    >>>

    We might also consider adding a specific section on container topics and small topics - we could call it "limits of topic orientation", equivalent to the "limits of specialization" topic later in the spec. That would give us a place to talk about some of the edge cases in detail without overly weakening the main points of the section on topic orientation.

    Michael Priestley
    IBM DITA Architect and Classification Schema PDT Lead
    mpriestl@ca.ibm.com
    http://dita.xml.org/blog/25


    "Grosso, Paul" <pgrosso@ptc.com> wrote on 12/21/2006 10:42:00 AM:

    > I don't disagree with Eliot and Scott that the wording about
    > topics could perhaps be clarified a bit, though I consider
    > that mostly editorial and not a substantive issue in the spec.
    >
    > I don't have much of an opinion about title-only topics or such.
    > It's difficult for the DTD to enforce good practice anyway, and
    > no matter how hard you try, a determined user will figure out
    > how to do something they probably shouldn't do.  (Your bullet,
    > your gun, your foot.)
    >
    > I will say, though, that I have less sympathy with the legacy
    > conversion issue.  DTDs in general--and whole technologies like
    > DITA in particular--are designed to be optimized for a specific
    > set of requirements and expectations.  If a square peg doesn't
    > fit into a round hole, you don't mess up the hole, you do something
    > about your peg or you look for something with square holes.
    >
    > I don't know if DITA sections should be nestable (some in-house
    > Arbortext users did ask for this too, but again, I think they
    > were trying to figure out how to map DocBook into DITA), but I'm
    > pretty sure I don't want to be driving DITA design by considerations
    > of legacy conversion.
    >
    > If you've got stuff tagged using another tag set/DTD, my first
    > question is why retag it?  What's wrong with the way it is now?
    >
    > If there are really good reasons why it is actually worth the
    > effort to retag it using DITA, then by definition, there should
    > be good reasons to *rewrite* it in a topic oriented fashion rather
    > than trying to cram non-DITA-isms into the DITA mold.
    >
    > Perhaps I'm over-reacting to the word "legacy", but I think we
    > need to consider extensions to DITA in light of actual topic
    > oriented related requirements rather than conversion issues.
    >
    > paul
    >
    > >


  • 5.  Re: [dita] What Is A Topic

    Posted 01-03-2007 03:00

    Defining a topic is, I suspect, going to be as slippery as any other "you know it when you see it" thing.  It's clear from the responses so far that some have a functional definition (it answers one question or described one thing), others have a content-model definition (what the DTD permits), others have a unit-based one (to be authored, or read, in one piece).

    Being a fan of specialization, and being a programmer first, my perspective on what a Topic is is based on heredity.  That is, my working definition of Topic is as the ancestor of *all* DITA document types, past, present and future.  The existing core specializations (task, concept, reference) are fairly light reworkings of Topic, but so much more is possible with specialization.  I don't find it difficult to imagine a specialization which benefits from, or perhaps relies on, the minimal content model of a topic with neither shortdesc, abstract nor body.

    Case in point: look at how Topic allows non-sections to follow sections.  It's hard to justify this content model in Topic by itself, but in the context of a Task, it's perfectly natural to follow a prereq with steps.  Another example has already been referred to, with the body-less glossentry specialization.

    I'd hate to render some future specialization impossible because of a failure to sufficiently imagine the diversity that specialization can bring.

    [Oh, BTW, Hi everybody.  I'm new to OASIS but I've been kicking about on the dita-users and DITA-OT lists for quite a while.  I'm a programmer-turned-writer at a software-for-the-plastics-industry company, and I'm inflicting DITA onto my co-workers mercilessly.]

    --
    Deborah Pickett
    Deborah_Pickett@moldflow.com