-------------------------------------------------------
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