OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

Groups - DITA TC Meeting, 7 April 2009 (DITA_TC_meeting_7_April_2009.txt) modified

  • 1.  Groups - DITA TC Meeting, 7 April 2009 (DITA_TC_meeting_7_April_2009.txt) modified

    Posted 04-11-2009 18:03
    -------------------------------------------------------
          OASIS DITA Technical Committee Minutes
                    Tuesday, 7 April 2009
    -------------------------------------------------------
    
    Minutes recorded by Kristen James Eberlein.
    
    
    1. ROLL CALL
    Quorum is present.
    
    
    2. Approve minutes from previous business meetings:
    * http://lists.oasis-open.org/archives/dita/200904/msg00000.html
    Motion made to approve minutes; seconded by Jim Earley; motion carried by
    acclamation.
    
    
    3. ITEM: Cross-references to Topicheads and Implicit Title-only Topics
    * http://lists.oasis-open.org/archives/dita/200901/msg00039.html (Eliot,
    others)
    * Action: Eliot to resume discussion on the list to help drive for TC
    closure here
    o http://lists.oasis-open.org/archives/dita/200903/msg00086.html (Kimber's
    latest issue summary)
    o http://lists.oasis-open.org/archives/dita/200904/msg00030.html (Priestley
    latest in thread--read back)
    Don Day mentioned that there had been increased activity since he posted
    the agenda, thus not all e-mail exchanges are listed. The last e-mail on
    this topic was from Michael Priestley, who asked Elliot Kimber "Why is it
    acceptable for href and conref to mean different things, but not href and
    keyref?"  
    
    Elliot: The fundamental question comes down to making a clear distinction
    between linking and addressing. The form of address shouldn't matter; what
    matters is that you are  pointing to a topicref and that topicref is acting
    as an indirection or not, depending on what the author intended. Or what
    the spec says the case always is. The objection that I had to Michael's
    last statement was that it's not whether we define what href means
    (different from what keyref means); the issue is that we define what it
    means for an xref to point to a topicref--by any form of address--or we
    don't. If we don't, we are continuing to leave it [what it means to have an
    xref to a topicref] ambiguous. If we state what it means to have a xref to
    a topicref, we're not changing the meaning of either keyref or topicref,
    becuase keyref has already established that topicrefs act as indirectors.
    And that leaves us with two choices: 1) We state that an xref to a topicref
    (by any form of address) is always an indirection to the ultimate target of
    that topicref, or 2) We state that an xref is either a reference to a
    topicref or a topicref target -- based on some value that the author of the
    xref specifies on the xref. And my proposal was that the type attribute
    provided such a mechanism.
    
    Michael: I disagree, because of the example that I gave: A link to a
    topicref might resolve to a link to a target within the navigation pane.
    This would apply in a context in which there is a navigation pane, but it
    would not apply in a context where there was not a navigation pane. So, if
    you are saying that it would be a question of authorial intent, that
    wouldn't make sense, since you'd want it to resolve differently when you
    output to different media. You wouldn't hardcode the expected display
    semantics or the expected way to resolve the target, whether you ignore the
    intermediate step or link to the intermediate step depends on whether the
    intermediate step (the map) is an addressable target in any output space.
    
    Elliot: But that's a problem with the notion of addressing navigation
    components at all; you already have that problem in DITA because you can
    have different output paths. There always can be artifacts in the rendition
    which could be usefully specified as link targets that you may not have a
    way of describing as authored. But it certainly -- the notion that there
    is, in any rendition, some sort of navigation artifact (TOC, separate topic
    view, whatever) seems fairly consistent to me. It seems hard to mention a
    useful rendition which would not have some sort of TOC.
    
    Michael: Embedded help?
    
    Elliot: Even embedded help has to have some way of getting to a larger
    context.
    
    Michael: The larger context might be the application. And the application
    itself might not be Web addressable. This is a real case. If you are using
    DITA for context-sensitive help, in which something like hover help or text
    is displayed within the application screen; the application screen might
    not be Web addressable.
    
    Elliot: Hold on. Web addressability is not the issue. What is the issue is
    whether a navigation relationship be established within a rendition
    context. It has to do with addressability and navigability in the context
    of the rendition.
    
    Michael: It's perfectly reasonable for me to imagine a case in which you
    are publishing a collection of topics for which the navigation is going to
    be assembled based on metadata in the topics, rather than being a
    separately addressable map-based artifact. One example here might be
    publishing to a MediaWiki wiki.
    
    Elliot: I've offered a cross reference because I think that there is
    something at the other end of it that I want people to go to. I either
    author it because I have a reasonable expectation that thing is going to be
    there -- and normally that would be a topic -- And I can't think of a real
    use case in which I'd want to link to a navigation context -- then this
    inherently becomes a presentation-specific version of that link, and I
    think I can author that reliably the same way that I author anything else,
    by specifying output=print or output=help system that has an addressable
    navigation context. But I don't think that this should speak to the
    fundamental nature of the addressing versus linking issue.
    
    Michael: What is the driving force behind defining the expected output
    behavior for xrefs to topicrefs in DITA 1.2?
    
    Elliot: I am not defining the expected output behavior; I am defining...
    
    Michael: Well, you are saying that it should resolve to whatever the target
     Effectively the topicref should be treated as an indirection mechanism in
    that case, unless there is some specific attribute setting to say
    otherwise.
    
    Elliot: Correct. And that's about the relationship established by the
    author between two pieces of information in the content as authored.
    
    Michael: What are you proposing for DITA 1.2?
    
    Elliot: That an xref to a topicref is always an indirection to the ultimate
    target of that topicref, unless you say type=something which means that the
    xref is really to the topicref itself.
    
    Michael: What is the business case for making this something that we define
    in DITA  1.2 as opposed to DITA 1.3?
    
    Elliot: There are two different things: 1) From a xref, it doesn't matter
    whether I use href or keyref to point to a