[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - DITA TC minutes, 19 May 2009 (DITA_TC_meeting_19_March_2009.txt) uploaded
------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]