minutes20110712.txt

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

DITA Technical Committee Meeting Minutes: 12 July 2011

Chaired by Don Day <donday@bga.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>

The DITA Technical Committee met on Tuesday, 12 July 2010 at 08:00am PT
for 55 minutes.

 * Regrets:  Jang Graat, Kristen Eberlein, Richard Hamilton

8:00-8:05 Roll call: Quorum was achieved.


STANDING BUSINESS:

Approve minutes from previous business meeting:
 * (http://lists.oasis-open.org/archives/dita/201107/msg00005.html
(Bruce Nevin, 5 July 2011)

Moved by Don Day, but approval deferred until next week because of delay
posting them.

 * JoAnn volunteered as scribe for July 19 and 26 while Bruce is away.


Subcommittee/liaison reports:

 * OASIS DITA Semiconductor Information Design Subcommittee (5 July
2011-Beims)

In Bob Beims's absence, postponed until next week. 
OASIS DITA for the Web 2.0 Subcommittee will follow next after that. 

ACTION (Don): Renew contact with Bob Beims re the Semiconductor
Information Design Subcommittee reporting next week.
ACTION (Don): Contact John Hunt to be prepared to report for the Web 2.0
Subcommittee.


BUSINESS:

ITEM: Triage of DITA_1.3_Proposals list

   o Wiki page: DITA_1.3_Proposals

#13020: Needs Bob Beims to be present.

ACTION (Don): Ask Bob Beims if anyone is prepared to support #1320.

#13021 requires Su-Laine Yeo to be present.

#13022: Enable element-to-element relations without conref. Michael P.
said Specializing <topicref> could effect the same functionality. Is
this something sufficiently useful to be defined generally in the
vocabulary. Roughly equivalent to xlink extended link structure. This is
a completeness question; is there an expressed need for it? Not evident.
Example: link a figure to a section in a different topic. Linking to
non-DITA content at the element level. #13084 for semantic linking may
intersect this. Annotation of Shakespeare corpus in DITA. Relationship
table relates comments to individual speeches. There's no reliable
semantic basis for this. If there's no pressing need, we can revisit
this later. In the meantime, it can be demonstrated as a best practice.
DEFERRED.

#13023: <sectiondiv> in <li>. We have <bodydiv> and <sectiondiv>. Why
can't we use the latter in <li>? It's allowed in <p>, which is allowed
in <li>. The proposal is wider: allow <sectiondiv> anywhere that <p> is
allowed. This is a demonstrated pain point: Eliot was trying to create a
specialization for a client. The original design was just to put it in
<section>.  Allow deeply nested sections where all the subheads are
generated. Eliot: that was the motivation for <bodydiv>. The motivation
for <sectiondiv> was to be just like <bodydiv> but not allowing nesting.
This may require a new element. <itemgroup> may be more appropriate. The
needed specialization must be specialized separately from <bodydiv> and
from <sectiondiv>, and this would mean a third specialization for the
same requirement. Do we widen the scope to allow <sectiondiv> in more
places or do we create a new more broadly distributed element for
specialization. The new element would not contain <section>, but would
allow arbitrary nesting of untitled things. Could we allow <itemgroup>
to nest, etc.? No, that would still require three different
specializations for the general requirement. Robert has clarified this
item in the table. ACCEPTED.

#13024: Meaningful Values for type= on <xref> and <topicref>. Was an
unqualified element type name. It needs to allow qualification,
module/elementtype, to avoid ambiguity if the same name is used for two
specializations. Is this a conformance documentation issue? It's an
update to the section spec that talks about the type attribute, although
not all processors check the type attribute. Allowing it makes sense;
mandating or recommending it could be problematic. It hasn't been an
issue in practice because so little specialization has been done
(outside of IBM). With the potential for aggregation of content from
different sources, this could become a problem. ACCEPTED.

#13025: Organization of Tagname The formulation here doesn't work.
DROPPED.

#13026: shortdesc element in a DITA map. Distinct from the metadata
cascade discussion. We say that it's possible, but we don't say how. We
might do something along the lines of @lockmeta and @locktitle. Maybe
rules for @lockmeta to make the metadata in the map override not just
locally but absolutely. Eliot volunteers to back up Kris as champions of
this item. ACCEPTED.

#13027: Allow draft-comment universally. Eliot volunteers to add his
name. This is easy to fix in the content model; implementation details
may be problematic. What does "universally" mean? The proposal must be
made more explicit. Eliot: anywhere you can type text. ACCEPTED.

#13028: Underspecification of @refcol. The DITA 1.1 specification for
simpletable's @refcol attribute gives very little insight into how it
should be implemented. It appears that the original intent at the time
might have anticipated the "associative linking" thoughts that have
since matured as the keyref processing specification. Did we fix this in
1.2? Is this addressed in the automated linking proposal for 1.3? The
issue is confusion, what's this for; we responded that it has no
function currently. We don't need to specify a new behavior for @refcol.
DROPPED.

#13029: <text> should be allowed just about everywhere. It's not allowed
in places where <ph> is not allowed, and this limits us to using
<keyword> to insert text content. No one has started using <text> yet,
so there hasn't been occasion for user complaint. Very similar to the
<draft-comment> issue. ACCEPTED.

#13030: Allow markup-based tables within fig, allow graphic-based tables
within table. Both fig and table serve to associate titles with
graphical presentations of data. Could not have a <table> contain a
graphic. Also, a drawing in a figure happens to be made with <table>
markup. Users complain about too many different ways to work with
tables; this may be a complexity issue. The content model for <fig> and
<figgroup> may not be extensive enough, w.r.t. Debora Pickett's proposal
for DITA 1.2 and 1.1 if it was incompletely implemented.

We will continue discussion on #13030 next week.