OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: DITA Technical Committee Meeting Minutes: 9 August 2011


DITA Technical Committee Meeting Minutes: 9 August 2011
Chaired by Don Day <donday@bga.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
 
The DITA Technical Committee met on Tuesday, 9 August 2011 at
08:00am PT for 55 minutes.

8:00-8:05 Roll call

 * Regrets: Kris Eberlein, Adrian Warman

> Quorum was established.
> A new scribe is needed. This is a highly visible opportunity
with many benefits as pointed out by Don in email.


STANDING BUSINESS:

Approve minutes from previous business meeting:

 * http://lists.oasis-open.org/archives/dita/201108/msg00004.html
(Nevin, 2 August 2011)

Moved by Don, seconded by Dick Hamilton, approved by acclamation.

Subcommittee/liaison reports:

 * OASIS DITA Adoption TC (JoAnn, 9 August)

   o Working to settle the stylesheet issue with Oasis, working
with Chet Ensign (the "new Mary McCrae"). We have the old specs
for PDF, nothing for HTML. Questions sent last week, no response
yet.

   o Work on articles is ongoing. The first with the new process
is on DITA and XLIFF is on the wiki. Reviewing an article on
machinery task by Jan Graat. Bruce's two articles on generic text
and on specialized convenience elements in maps need someone else
to take them over. 

Being an author for the Adoption TC is a highly visible
opportunity, and it can pave the way for conference
presentations, etc.

Don will determine with Lisa Dyer as to which comes first in the
next two weeks, OASIS DITA for Programmers Subcommittee (Lisa),
or OASIS DITA Technical Communication Subcommittee (JoAnn)


BUSINESS:

1. ITEM: Triage of DITA complexity list and potential solutions

   o Wiki page: http://wiki.oasis-open.org/dita/DITA_Perceptions

   o NEW: Stan's summary: http://lists.oasis-
open.org/archives/dita/201106/msg00027.html

 * Closure pending open actions

> No discussion this week.


2. ITEM: Triage of DITA_1.3_Proposals list

   o Wiki page: http://wiki.oasis-
open.org/dita/DITA_1.3_Proposals

13031:
Extending the highlight domain: element for strikeouts. The
semantic function of strikeouts is good to capture. Don supports
as an obvious element, but one that we would not expect to be
specialized. Overbar should be added with it. With underscore
these are the three most common cases. <flag> usually has a
property indicating low or high, is this subsumed as a flag? No,
this is among the typographic conventions that pervade financial
documents. Will it be markup or a property? Highlight should
include a list of all the values available in ditaval. There's an
argument for having all typographic matters be properties as
distinct from semantic elements. Is there any objection to
topographic matters being like strikeout being redundantly
conveyed both by elements and by properties? There's no well
defined way to handle all such properties in DITA. These are
design issues. Motion to accept the core proposal.

ACCEPTED

13034: 
"formatting" domain for capturing arbitrary formatting. This is a
problem in the publishing domain, though it may seem excessive
from a tech docs point of view. Does this add too much to
complexity? Do we publish such things separately as committee?
This sounds like styles. It's not appropriate for DITA right now,
but should be taken up by a subcommittee. Eliot doesn't have a
community yet to form that subcommittee. This represents a
community of practice, more than the TC as a whole. Proposed to
make this the business of a future subcommittee. No disagreement.


Eliot identified "publisher" items to move into a separate list,
and will coordinate with Robert on the disposition of the list of
1.3 proposals. 13032-13034 are all available in the DITA for
Publishers project, and there's no barrier to their use. 

13032: 
As much about fixing <bookmap> as it is about a publishing
domain. Because <bookmap> is a single map domain, it doesn't
provide any mechanism for extension, and that affects a number of
technical documentation cases. Have publication metadata in a
separate domain from topicmeta, as pioneered by learning and
training. <bookmap> doesn't allow any peer to chapter, but a map
domain could. In a publication it's common to have a chapter
followed by parts. By being overconstrained, <bookmap> blocks
some legitimate uses, parallel to the case with <task> and
<strict-task>. Given a general domain for pub metadata and a
domain for topics we could do that. We need a way of saying map A
represents a publication and map B doesn't, it's a root map
that's not intended to be a publication. JoAnn: let's be careful
about making it difficult to teach people how to author and lose
adopters. People were wanting to use DITA without having to hire
a consultant. Eliot: Has users whose requirements cannot be met.
The proposal is sufficiently general that it will not constrain
others. Don: what would be the loss if this were not included.
Eliot: Users with such use cases would have to replicate the work
done in the DTIA for publishers project. Nancy: but that's
available. Eliot: Most users won't see that, or won't see their
situation as a publisher's use case. We've already codified an
approach through the L&T model, but that's too specialized.
There's a map metadata domain for richer metadata, and there's a
publication map domain with a catalog of topicref types for all
kinds of things that can occur in a publication, wrappers around
groups, mapref types, topicref types that can be the root of
submaps, that sort of thing. These can be combined in one domain,
or mixed into existing domains. 

We'll have to continue the discussion in email and on the call
next week.

8:50-8:55 PT Announcements/Opens

8:55 PT Adjourn





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]