[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - DITA TC Meeting, 7 April 2009 (DITA_TC_meeting_7_April_2009.txt) modified
-------------------------------------------------------
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 <topicref>; it means the same
thing. Whatever it means, it means the same thing.
Michael: To clarify, for an xref to point to a topicref with a keyref, in
my mind, would have to mean that the topicref pointed to another
topicref.
Elliot: No. Here's the thing. A keyref is a pointer to a topicref that
defines the key. That's all it. The keyref by itself is not a indirector;
it is the topicref that is the indirector. The fact the I referenced the
topicref by keyref is irrelevant for the point of determining whether that
topicref is a keyref is an indirector.
Michael: That's your assertion.
Elliot: Yes, and this is an assertion that is based on the fundamental
principle of hypertext systems, which is that form of address is not
important, the form of address does not determine the semantic of
relationship.
Michael: This brings us back to the question that started the call; why is
it OK for conref and href to behave differently?
Elliot: Because they represent different semantics. Keyref is a shorthand
for having a separate set of elements, one for each of our existing
elements, whose only semantic is use by reference of the corresponding real
element. So, if we have elements like that, they would use attributes
called href and keyref, because again the form of address is not important
-- what is important is the semantic of the relationship established.
Conref and conkeref establish a use by reference relationship; href and
keyref establish a use by navigation/link relationship
Don Day stopped the discussion; he suggested getting interested parties
together on a phone call to define a proposal for next week's meeting.
Elliot: The keyref feature is the single most important part of DITA 1.2.
Without keyref, DITA 1.2 has litle additional value for people for whom
DITA 1.1 cannot satisfy their business requirements. It's vital that we get
keyref right.
Michael: I need a statement from you about what you want changed in DITA
1.2. Lets not argue the basic architecture of the universe if we do not
need to.
Action (7 April 2007):
----------------------
Michael Priestley will arrange a phone call with Elliot Kimber. Other TC
members who are interested in this issue should contact Michael and let him
know of their interest.
4. ITEM: Hazard Statement Width
All action items are completed. Note the link to the new DITA 1.2
implementation issues:
http://wiki.oasis-open.org/dita/DITA_1.2_Implementation_Notes
This item can be removed from the agenda for next week.
5. ITEM: Mapref attribute resolution
* http://lists.oasis-open.org/archives/dita/200903/msg00007.html
(Anderson)
* http://lists.oasis-open.org/archives/dita/200903/msg00057.html (Robert's
summary)
o http://lists.oasis-open.org/archives/dita/200903/msg00059.html (Nevin's
response)
o http://lists.oasis-open.org/archives/dita/200903/msg00061.html
(Ogden's response)
o http://lists.oasis-open.org/archives/dita/200903/msg00065.html
(Robert's response)
o http://lists.oasis-open.org/archives/dita/200903/msg00068.html (Ogden's
wrap up)
One point still open; Robert is following up with people within IBM. Hopes
to send out a summary by the end of the week. There is an open question
about how the scope attribute should be resolved when it is on a mapref.
Action (7 April 2009):
----------------------
Robert Anderson will write another summary (with a lot of context about the
discussion, where it originated and where it went) and send it to the
list.
6. ITEM: Editorial Style
This item is deferred until Gershon Joseph is present.
Action (?):
-----------
Gershon Joseph needs to add the Editorial style page to the Wiki.
7. New ITEM: Proposal for new Tech Comm. Subcommittee:
* http://lists.oasis-open.org/archives/dita/200904/msg00002.html
Don iterated that our discussion today would be general, awaiting Gershon's
return later in the month. He asked how might we assess interest in this
proposed subcommittee and determine who the constituency might be?
Kris Eberlein gave a brief summary of how this emerged from an Adoption
Committee meeting: Several members commented that the material in the
architectural spec that they find most useful is the tech-comm specific
topics: concept, task, and reference. Now that the techcomm material is
being removed from base DITA and into a tech comm package, Adoption
Committee members were concerned about how that material would be
maintained and cared for.
Discussion about packaging ensued, and whether each package needs a
subcommittee.
Michael Priestley stated that both Machine Industry and Learning and
Training had subcommittees. In the list of doctype shells, the technical
content collection is listed as as explicit collection. It subsumes both
the software and programming stuff and the machine industry task.
Paul Grosso raised a point about whether we we talking about subdirectories
versus subcommittees. We have subdirectories for base, machine industry,
learning and training, and bookmap. Are we suggesting to have a
subcommittee for everything that is not base?
X (Bruce Nevin?) stated that his interpretation of the request for a new
subcommittee was the fact that technical communication was a very large
part of the adoption user base
Michael commented that he had been looking at the list of doctype shells.
There the main splits are base, technical content (includes bookmap,
classification map, machinery task), learning and training (which contains
learning& training-specific versions of general task and bookmap). The
subdirectory or shells should not dictate our subcommittee structure, but
as we split our the base DITA content from the specializations -- so that
we can talk clearly in the architectural spec about base topic and base map
-- that does mean that we'll have a separate package for technical content.
Having a subcommittee that would be willing to focus exclusively on the
technical communication content (including concept, task, and reference)
and their usage does seem reasonable and parallel to learning and training,
which is also discipline-specific.
Don reminded us that the point of this discussion was to raise awareness
and help focus discussion on the e-mail list.
Nancy Harrison stated that she also thought that care and maintenance of
the technical communication material was a legitimate concern. DITA started
with technical communication. The TC needs to be committed to owning and
maintaining anything that it removes from the base -- or turn over the
ownership to someone else.
Don suggested that perhaps another scope for a proposed techcomm
subcommittee would be to propose and vet any new domains proposed by people
contributing into the techcomm space.
Michael stated that he sees a case for the tech comm subcommittee;
historically, DITA arose out of tech comm, so we had a lot of tech comm
people focused on it. Now that it is being adopted into more and more
communities, it makes sense to have separate meetings, one to talk about
pure architecture and another to focus on techcomm-specific concerns and
messages. The packaging per se is not the driver; the packaging and
proposed subcommittee are both reflections of the same need. We need to be
able to focus separately on 1) the core architecture and its applicability
across domains, and 2) specific domain implementations of the
architecture.
Chris Kravogel raised concerns that spliting into so many subcommittees
would make it difficult to maintain an overview of DITA as a whole.
Don stated that the proposal has a level of appeal and support; he
recommended continuing discussion on the list. We should consider if there
are people beside the TC who would need to be involved, other professional
societies, for example.
8. ITEM: Review Master Topic List
* Latest spreadsheet:
http://lists.oasis-open.org/archives/dita/200904/msg00017.html (updated
this week)
* Subversion clients:
o Tortoise SVN:
http://lists.oasis-open.org/archives/dita/200904/msg00018.html
o Eclipse and oXygen:
http://lists.oasisopen.org/archives/dita/200904/msg00021.html
Don Day mentioned that Gershon Joseph is out for the next two weeks; how
shall we best manage interim work? There was a brief discussion of who
would be responsible for conducting regular builds of the architectural
spec; Robert Anderson made it clear that this was not in the realm of his
responsibility. Since it is unlikely that any builds will be needed in the
next two weeks, this issue can be left unresolved for now. After
discussion, we agreed that Don will handle responsibility for the master
spreadsheet until Gershon returns.
Action (31 March 2009):
-----------------------
Gershon Joseph to add content to the Wiki to cover the basic tasks that
users will need to do with Subversion.
Meeting adjourned.
-- Kristen Eberlein
Information about the document named DITA TC Meeting, 7 April 2009
(DITA_TC_meeting_7_April_2009.txt) has been modified by Kristen Eberlein.
Document Description:
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=32028
Download Document:
http://www.oasis-open.org/committees/download.php/32028/DITA_TC_meeting_7_April_2009.txt
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]