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: Groups - DITA TC Meeting, 14 April 2009 (DITA_TC_meeting_14_April_2009.txt) uploaded


-------------------------------------------------------
      OASIS DITA Technical Committee Minutes
                Tuesday, 14 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/msg00045.html (7 April
2009)
Motion made to approve minutes; seconded by Stan Doherty; motion carried by
acclamation.


3. SUBCOMMITTEE REPORTS
* OASIS DITA Machine Industry Subcommittee 
Chris Kravogel gave a brief report. The subcommittee is now working on what
they want to see in DITA 1.3:
	o Values and tolerances	
	o Filtering and attributes for conditional processing
	o Elements for maintenance, spare parts, diagnostics, and
troubleshooting
	o Updated attributes for hazard statement


4. ITEM: Cross-references to topicheads and implicit title-only topics
* http://lists.oasis-open.org/archives/dita/200901/msg00039.html (Eliot,
others)
* Action (7 April 2007): Michael Priestley to arrange call with Eliot to
bring new proposal to list.
Don reported that Michael Priestley and Elliot Kimber had a good
discussion. Elliot reported that they had come to a basic agreement. Elliot
has sent Michael a list of proposed changes to the Language Specification,
which Michael currently is reviewing.  
In essense:
1) An xref or link via href to topicref is always a pointer to the
topicref. This is independent of whether the topicref has a keys
attribute.
2) A topicref is only a redirector when it is referenced by a key (not a
href)
3) The spec currently is silent about what it means to have an xref or a
link to a topicref; they propose that the spec state that processors may
treat the reference as a direct reference to the topicref, but can also
choose how to implement it.

Action (14 April): Michael or Elliot will present a summary to the e-mail
list which  we can vote on next week.


5. ITEM: Mapref attribute resolution
* http://lists.oasis-open.org/archives/dita/200903/msg00007.html (Anderson
interim summary)
Robert reported that his e-mail (14 April) summarized the two outstanding
issues: 
1) Cascading/inheritance of attributes through map references, such as toc
and linking
2) Treatment of scope attribute and whether scope cascades through to the
target map (similar to toc and linking) or is inheritantly part of the
reference (similar to format and href)
No discussion ensued.
Action (7 April 2007): Robert to write a final summary. 


6. ITEM: Case for aggregated editing
* http://lists.oasis-open.org/archives/dita/200903/msg00014.html
Anne Rockley and Steve Manning were present, and Steve gave an overview.
Change management issues are greatly amplified in a business environment.
Reuse is not the initial driving factor, although business users will
eventually develop an interest. The typical users are not used to creating
topics; they create documents. They started with assumption that a CMS
would be in place, and that enterprise business documents would be authored
not by teams of 4-5 people but at a corporate level. 

The basic scenario is What would be needed for user to open a topic-based
document, and have it look like a document, although they actually would be
editing topics?

They started thinking of using ditabase, but then began thinking of using
map as the key aggregator. This would create an onus on tool vendors to
devise solutions to create the "virtual document" to be presented to the
user, which presents a lot of technical problems. They came to the idea of
creating a specialized version of map, maybe a specialized version of
ditabase.

The subcommittee wants feedback from the TC; they had a flurry of responses
from individual TC members, but is now asking for additional discussion and
feedback.

Su-Laine Yeo: What's wrong with simply using ditabase?
Steve: It potentially could, but has an impact on reuse and collaborative
work unless a CMS is in play. For example, RFPs, different people or
divisions (marketing, sales, engineering) own different sections. So you
want to maintain individual topics, but also be able to assemble then on
demand to present them to the business user.

Elliot Kimber: From an architectural standpoint, this shouldnt be
necessary. You are in a hard place. The standards committee can't take a
position to accommodate users whose tools don't support the standard. We
can't implement design solutions that are workarounds for non-conforming
tools.

Don Day: Remember that this subcommittee needs to publish its findings, and
that its report may be a summary rather than a request for architectural
changes to the standard.

Don: Since you need the ability both to validate at the per topic basis --
but also to "bundle" topics  can you take anything from the process that
the toolkit uses to create the merged file?
Steve: We looked at that as a potential interim solution. But how do you
reverse that structure? How do you take a single flat file and burst it out
into the right individual topics?

Don: Are you trying to veil the processes from the general XML editors?
Anne Rockley: We were trying to focus on DITA-capable tools in the business
environment; our assumption is that users would be working with a DITA
aware tool, but some people will be working with general XML editors that
are not DITA aware, such as XOpus and other tools that people use to edit
Web pages.

Elliot: If you are creating an aggregation of topics in a single file, and
then recreating the topics from that single file, you need to capture the
original topicref attributes from the map  A possible solution might be a
domain specialization from data that provides a place to put all the
properties from the original topicref elements. This wouldnt require
adding attributes to the topic element.
Steve: That might be an excellent solution.

Anne: We see our focus as addressing the question of How can overcome some
of the hurdles? Lots of companies are adopting DITA for business
documents; others are rejecting it. So while we might not be suggesting
changes to the DITA architecture, we want approval of OASIS as we publish
recommendations or suggestions.

Don: Do people see problems with the directions that Steve and Anne have
outlined? Any land mines to avoid?
Elliot: Has a general objection to ditabase approach; it's unnecessarily
crude instrument. People should be able to develop shell DTDs that allow
the aggregation of the topic types without the full openness of ditabase.

Paul Grosso: Avoiding understanding topic-based writing is, in the long
run, problematic. I hate to have the TC approve a document that advocates
avoiding understanding topic-based authoring or the underlying paradigm
shift.
Anne: Not all documents in the enterprise business environment are topic
oriented. This is a huge initial acceptance issue, much larger in this
context than in tech comm. 

JoAnn Hackos: Resolve for edit view in Arbortext Editor has been used for
years. Why can't we suggest similar implementations to vendors?
Anne: That's one of the possibilities, to suggest certain implementations
and best practices for vendors. (A lot of the other tools do not have this
functionality.) Are we in agreement in OASIS that we can put forth this
idea as a recommendation  that vendors should implement such functionality
if they want to move into the enterprise business document space?
Don Day: We did set up the subcommittees to represent the needs of the
individual, constituent communities. Recently weve been running into issue
of whether we can actually approve statements that would seem to be OASIS
actually recommending different tools. We need parse the discussion so that
it comes out as a recommendation, or direction, guidelines rather than
absolute tasks. We have talked about a DITA conformance suite, which would
provide vendors with a standard target for how they handle DITA  while the
means by which they represent DITA for different communities could be
entirely separate. Useful to provide domain-specific guidance to vendors.

Don: Very useful discussion, might help other subcommittees that are
struggling with recommendation to move forward. Will leave this on the
agenda for next week, need to have more discussion.
 
Meeting adjourned.

 -- Kristen Eberlein

The document named DITA TC Meeting, 14 April 2009
(DITA_TC_meeting_14_April_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=32161

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