OASIS Darwin Information Typing Architecture (DITA) TC

Expand all | Collapse all

Groups - DITA TC Meeting, 14 April 2009 (DITA_TC_meeting_14_April_2009.txt) uploaded

  • 1.  Groups - DITA TC Meeting, 14 April 2009 (DITA_TC_meeting_14_April_2009.txt) uploaded

    Posted 04-20-2009 15:05
    -------------------------------------------------------
          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
    


  • 2.  Aggregated Editing

    Posted 04-25-2009 13:16
    Dear colleagues
    
    I have been following the discussions on aggregated editing, and particularly the issues raised at the last meeting. (I'm sorry that my time zone makes attending meetings problematic.)
    
    Some years ago, I spent a lot of time using a hypertext authoring tool called HDK, and it's successor, XDK. It was built as an add-on to Word. Its architecture may provide some ideas for how aggregated DITA editing might work. 
    
    The HDK project file stored project settings, as well as the "ingredient list" of the project. The ingredient list was a represented as a TOC-like tree. HDK was topic based, but the topics were stored and edited in Word. A project could be set up with one topic per Word document, or multiple topics per Word document. There could be one or many Word documents in the project. The sequence of topics in Word documents was irrelevant to the output, and irrelevant to the order of topics in the TOC. Included in the topic's metadata (stored in the ingredient list in the project file) was the file name of the Word document in which the topic lived, and the unique topic identifier (effectively a Word bookmark name) within that document. A hard page break served as a topic divider; hard page breaks could not be used for any other purpose. A topic could be split into two through an HDK dialog box, which would result in a new page break and topic title being inserted.
    
    In other words, this approach allowed HDK to be a topic-based authoring tool within an aggregated editing environment.
    
    Translating that approach to a DITA environment, we would start with the ditamap being the aggregating plan. In an aggregated editing program yet to be developed (let's called it "Aggie"), when a ditamap was opened, the topics would be opened in sequence and dynamically merged into a linear document stream. Aggie would place some sort of topic divider token between topics. 
    
    When the user made a change to one topic in the document stream, the topic would be marked by Aggie as "dirty". When the user saved the "document", Aggie would save the changes back to the topic file name. When the ditamap was closed, 
    Aggie would then delete the temporary document stream. If a topic was split into two, or a new topic was added, this would be facilitated by the insertion of a new topic break token, topic metadata, and a prompt for a file name. 
    
    Any other operations within the Aggie editing environment, such as cross-topic cross-referencing, conreffing and reltable changes, would be handled in pretty much the same way as any normal DITA editor. This is because the linear document stream is only an illusion. You could still have other users using a different topic-based editor to edit the same topics. Different Aggie users could possibly use different ditamaps (or even conditions in the map) to work with a different aggregation of topics.
    
    As far as I can see, no changes to DITA would be required for Aggie to be created. Aggie might use ditabase for its temporary linear document stream, but that would be an application-specific format anyway. Aggie could probably use the ditamap as its "project" file, although if something fancy was required, such as the topics displayed in the aggregated form in a different sequence to the ditamap, then a specialised ditamap might be needed. Aggregated editing would be entirely an authoring workflow choice, and not an architectural decision.
    
    Hope this is useful.
    
    Tony Self