OASIS DITA TC Minutes for 28 June 2011

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

OASIS DITA TC Minutes for 28 June 2011
8:00-8:05 PT Roll call
   o Regrets: None

STANDING BUSINESS:

Approve minutes from previous business meeting:
   o http://lists.oasis-open.org/archives/dita/201106/msg00036.html (Bruce
Nevin, 21 June 2011)
Moved by Don, seconded by Kris, approved by acclamation.

Subcommittee/liaison reports:

   o OASIS DITA Technical Communication Subcommittee (28 June 2011)

> JoAnn: Have been talking about a proposal for a troubleshooting topic and its
relation to an existing IBM specialization. Also want to add a troubleshooting
element to <taskbody> in 1.3. One of the most interesting things is how this
fits in the metamodel that the BusDocs SC has been working on. As a
subcommittee, can we propose a specialization? If we don't want that to become
part of the primary DITA spec, can we propose a TC sub-specification? We think
it's probably not a good idea for this to be part of the primary specification.
Can the TC take up the notion of separate sub-specifications? Have other
subcommittees run into these questions? We felt that the Learning & Training
part of the spec should have been separate.

> Michael: the original proposal was to have separate spec documents. The
challenge was that documentation of just the specialized elements is not very
useful; but if you republish the core specification you're duplicating content.
Maybe we have to come to grips with cross-document linking.

> DocBook does this. The DocBook publishing spec is a simpler case, but OASIS
was OK with it.

> Can we do a TechComm specification, approved by the TC as part of the DITA
standard, as an add-on to DITA 1.2, not 1.3? Michael: Yes. One option: leave it
as a working draft in perpetuity. Another, get it approved as an additional
standard, as a valid peer document to the DITA 1.2 spec. The challenge there is
the effort of getting the 15% vote for the standard. If you're voting on just a
part of the whole, only those interested in that part will be motivated to vote.

> We should make an agenda item about how SCs can contribute portions of the
spec. Robert has added the proposed <troubleshooting> element for <taskbody> to
the DITA 1.3 list.

> Next week, the DITA Adoption TC will report. (The Pharma SC is inactive at
present.)

Action Items:

   o Review open items: http://www.oasis-
open.org/apps/org/workgroup/dita/members/action_items.php

Owners of items are encouraged to review the list and close items assigned to
them. Current owners are: Robert Anderson, Thilo Buchholtz, Stan Doherty, Kris
Eberlein, Eliot Kimber, and Chris Kravogel.

BUSINESS:

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

     * Wiki page: "What do people (really) mean when they say "DITA is too
complex"?

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

>No discussion.

2.	ITEM: Triage of DITA_1.3_Proposals list

     * Wiki page: DITA_1.3_Proposals

   o note Yeo/Kimber housekeeping matters

13004 and 13005 are now combined.

13006 "Future post DITA 1.2 work from Issue #12007: Item 4: Consider providing a
mechanism that would allow map authors to override references in maps and topics
even if references in the maps and topics were not authored using key references
or with indirect referencing in mind." 

>This is to facilitate reuse in different contexts without modification of the
topic (which triggers re-translation). It is related to addressing, but not
necessarily key-based addressing. Adding a parallel to keys raises complexity
concerns. It might be best to leave this as a task for a CMS to handle. But many
features that DITA now provides had to be handled by content management systems
before DITA provided a standard means. We decided to defer this.

13007 "Consider adding new values for @toc beyond {"yes" | "no"}: {"alway" |
"never"} or perhaps {"all" | "none") to provide greater control over what can be
overridden by what." 

>The issue arises because toc cascades. You could say 'never' and the nested map
couldn't turn it back on. What does 'yes' mean in the context of 'no'? How
should it be implemented? People may want to drop something from the TOC but
retain everything else below it. We certainly need to clarify the language. If
no doesn't mean never, then we need never, and if yes doesn't mean always, we
need something there. (There seems to be some similarity in 13059. Might there
be a general approach to how cascading works for a class of attributes. TOC is
in effect a conditional processing attribute, in respect to the output.) Robert
will write a proposal and write up how the interactions work, and is now the
owner of this item.

13008 "Consider adding @appid as a new optional CDATA attribute on <resourceid>
and making the existing @id optional." 

> The meaning of @id is overloaded in <resourceid>. This value is unrelated to
DITA IDs in the @id attribute. The change is trivial. It might better be
considered a bug (which has been present from DITA 1.0, showing that we should
never pre-implement requirements). We decided this should be included.

1309 "Keyref not sufficient for general indirection. keyref mechanism provides
no way to do renaming or splitting/joining of elements below the topic level." 

> In 1.2, Eliot proposed a general indirection mechanism. In view of complexity
issues, he is now happy to defer this. For completeness, this is a big hole.
Does that outweigh the complexity? Are there enough users who find it a serious
limiting factor? It seems best to make this part of a deeper re-architecting.
However, Chris is interested in taking it over, in the simplified description
that he would like to be able to bind an element to a key definition. This may
be related to 13022. Want to be able to refer indirectly to an element id as
well as a topic id. The challenge is at a design level. Until now, maps cannot
refer to anything below the topic level. We need to state the requirement more
clearly as allowing redirection of links to subtopic elements. This will be a
new row in the table. Then 1309 will be deferred.  

We will resume with item #1310 next week.

8:50-8:55 PT Announcements/Opens

8:55 PT Adjourn