Groups - DITA TC minutes, 19 May 2009 (DITA_TC_meeting_19_March_2009.txt) uploaded

[keberlein@pobox.com]

-------------------------------------------------------
      OASIS DITA Technical Committee Minutes
                Tuesday, 19 May 2009
-------------------------------------------------------

Minutes recorded by Kristen James Eberlein.


1. ROLL CALL
Present: Robert Anderson, Stan Doherty, Jim Earley, Rob Frankland, Elliot
Kimber, Su-Laine Yeo, Kris Eberlein, Gershon Joseph, Michael Priestley, Don
Day, Steffen Fredericksen, Jae Sheddy, Steve Manning, Bruce Nevin, Craig
Hughes

Quorum is present.


2. APPROVE MINUTES FROM PREVIOUS MEETING
* 
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200905/msg00020.html
Motion made to approve minutes; seconded by Bruce Nevin; motion carried by
acclamation.


3. SUBCOMMITTEE REPORTS
Anne Rockley sent regrets; we will have a report from the Enterprise
Business Documents Subcommittee on May 26.

Steffen Fredericksen announced that he expects to issue a motion to create
a Pharmaceutical Subcommittee by the next TC meeting (May 26). Don
suggested that he post materials to the list under the announcement of
Proposal for initiation of pharmaceutical subcommittee. This will be on
the agenda for May 26th.


4. ITEM: MAPREF ATTRIBUTE RESOLUTION
* How does @scope behave when cascading from map to map? 
*
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200905/msg00019.html
Robert summarized; the general consensus was when you have a <mapref>
element that points to another map and the scope=peer, the scope attribute
applies to the map reference itself; it does not cascade and apply to
topics in the map. Same behavior for scope=external. A group within IBM had
interpreted this otherwise, and Robert needed to check with them.

Motion that we formalize the proposal that scope attribute should not
cascade through map references; its presence on the <mapref > indicates the
scope of the map, Seconded by Elliot Kimber; approved by acclamation.

Action (19 May 2009):
---------------------
Robert to ensure that the question of how scope behaves when cascading from
map to map is properly addressed in the language and (if necessary) the
architectural specifications.


5. ITEM: processing-role attribute (Anderson) 
* http://lists.oasis-open.org/archives/dita/200904/msg00080.html
There have been additional recent e-mails about this item that Robert
Anderson has not had time to digest. Paul Grosso had asked that a decision
not be made until he was present.
Robert summarized:
1)	Does the processing-role attribute cascade to nested <topicref> elements
or through references to other maps? Roberts thought is yes; hes not sure
whether people have objected to this.
2)	Does the processing-role attribute cascade through <keydef> down to its
children? Roberts thought was If it cascades anywhere, then it cascades
through <keydef>.
3)	Which attributes does the processing-role interact with? When
processing-role=normal, there is no change from current behavior. When
processing-role=resource-only, print=no and toc=no; also the topic should
not be linkable or searchable. 
4)	When the processing-role attribute forces other attributes to take on
values (as in #3), does that become an explicit attribute that cascades
through? If processing-role=resource-only on a parent and
processing-role=normal on a child, the toc attribute is forced to no on the
parent  does that toc attribute cascade to the child as well? Robert
thinks that it should not, based on the principle of least astonishment.
And is this sort of markup valid at all? Is there any reason to have
children of a parent topic that has the processing-role=resource-only?
5)	What does it meant to have processing-role=resource-only and print=yes?
In such as case, Robert thinks the print attribute is ignored. Or
processors should issue a warning.
Deferred until next meeting, when Paul Grosso is present.


6. ITEM: THE CASE FOR AGGREGATED EDITING
* http://lists.oasis-open.org/archives/dita/200903/msg00014.html 
* http://lists.oasis-open.org/archives/dita/200904/msg00099.html (TSelf
comment) 
Steve Manning started with an overview of the problem: The typical
business-enterprise-document authors do not create topics; they create
documents. Dealing with topics (rather than documents) is one of the key
stumbling blocks in getting DITA accepted, so the subcommittee identified
idea of aggregate editing as a key aspect of the authoring experience. This
led the committee to look at mechanisms by which they could support users
needs for aggregated authoring:
1) Changes from vendors to support an aggregated editing approach; users
could open a map and see a virtual aggregated document
2) Additional functionality through the DITA Open Toolkit or separately to
read a DITA map file, aggregate topics together in a temporary file for
editing, and then burst them apart back to the originating topics.

One thought was to put together a spec for vendors, but Steve is wary about
this approach as he is concerned that it might be interpreted as favoring
one vendor over another.

The subcommittee is having a vendor demonstrate this type of functionality
to them on their regular meeting on May 25th. They also have encountered
DITA users who have created scripts to aggregate topics from a map into a
master topic, for purposes of both creating an aggregated editing
environment and enabling them to validate the document as a whole.

Don commented that in the future, he thought that activity on this item
could be tracked as part of the regular subcommittee reports. He then asked
if there were comments or questions from the TC. 

Michael Priestley commented on the three options that the subcommittee had
proposed in their thought piece:
1)	Using map as a key aggregator will be more complicated than it looks; it
would need to maintain *multiple* different virtual documents rather than
one, each with separate DOMs and schema validations per DOM. Ideal
solution, but would require each vendor to rework their support for XML
from scratch. Huge work item and so probably not realistic
2)	Using ditabase as the aggregator would require the tool (editor or CMS)
to manage the reuse. Michael has serious concerns with this approach, since
one of the key values of DITA is how it standardizes the reuse mechanism.
Would be walking away from conref and map-based reuse and leaving it up to
the tool, which would inhibit interoperability and break the promise of
portable reuse relationships.
3)	Round-tripping between maps and ditabase. This is the idea of managing
aggregation as a specialized map that is limited to the types of hierarchy
that can be expressed in database, and then have a preprocess step that is
standardized rather than tool dependent. This leaves people with the
problem of mismatched domains but avoid tool-dependent reuse. This seems
the most promising solution.

Steffen Fredericksen raised the point that he thought that an aggregated
editing environment (which obscures the nature of the topics to the author)
would highly increase the likelihood that the topics would be written in a
very context-sensitive way that would inhibit reuse. He also commented that
it would increase the likelihood that authors would overwrite over authors
work on any reused topics.

Don Day commented that he sees lots of overlap with the proposed publishing
subcommittee; the scope of this issue might be larger than enterprise
business documents.

Elliot Kimber commented that publishers who want to conveniently author
narrative documents have a similar requirement; he has addressed this with
clients by creating shell DTDs that enable direct topic nesting. However,
this sort of solution does not address the issue of having distinct topic
types with distinct content-model constraints that can be edited in an
aggregate way without unifying the content model.

Jim Early interjected that this is tool dependent; whatever the content
model allows, if the tool supports it in an aggregate form, then it should
be able to do that.

Michael Priestley stated that map-based aggregated editing will work in a
single organization where domains and DTDs and content models are arranged
ahead of time. This is the scenario that we need to focus on, but it
requires a closer coordination between the participating doctypes than is
required in other scenarios. With map-based aggregated editing, we might
need to have additional requirement that domains need to match across topic
types.

Elliot: This is awfully close to creating local shell DTDs that implement
the coordination.

Michael: But that doesnt handle the map-based aggregation requirement. I
am focusing on the map-to-ditabase round tripping, and in that context,
database is equivalent to local shell DTD. Need to specialize map to
allow for predicable round tripping -- eliminate <topicgroup>, for example,
and other elements that do not have an equivalent in the content world. The
transformation doesnt present any technical problems, and the resulting
document, because it has a normal DTD will be editable using normal
tools.

Don: Want to keep liaison between Enterprise Business Documents
Subcommittee and the emerging publishing subcommittee. Both groups might
work together to propose profiles of some sort that help tools manage how
they interoperate with single topics, collections of topics, or aggregated
topics; by profiles, I mean ways of declaring from outside of the standard
ways in which the standard can be used in a consistent and verifiable way.
Since there is no decision for the TC to make, this item will be closed.


7. ITEM: REVIEW MASTER TOPIC LIST--Gershon
Reminder again that we are maintaining spreadsheet in SVN; be sure to lock
the file before making changes, since we cannot merge this file as we can
merge TXT files.

No formal writing guidelines yet; have received material from Stan Doherty
that the Help Subcommittee used.

Gershon queried authors about their progress and issued a reminder for
authors to check in material as they go. Elliot Kimber has volunteered to
take the specialization topics previously assigned to Gershon.

Actions (19 May 2009):
----------------------
1.	Kris, JoAnn, and Gershon to create values for the Review Status column
in the spreadsheet.
2.	Kris to ping Erik Hennum about the topics that he is currently assigned
in the spreadsheet. Either Gershon or Elliot could take on these topics and
ping Erik if help is needed.

Meeting adjourned.

 -- Kristen Eberlein

The document named DITA TC minutes, 19 May 2009
(DITA_TC_meeting_19_March_2009.txt) has been submitted by Kristen Eberlein
to the OASIS Darwin Information Typing Architecture (DITA) TC document
repository.

Document Description:


View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=32602

Download Document:  
http://www.oasis-open.org/committees/download.php/32602/DITA_TC_meeting_19_March_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