[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]