Re: [dita] DITA Technical Committee Meeting Minutes: 29 March 2011(v2--amended actions and links)

This version amends the actions and links for the key resolution
    discussion. My apologies for the botched notes. Please note revised
    actions per Kris's corrections.

    

    
-- 

      

        
 Don R. Day 

        
 DITA and XML Consultant,
          512 244-2868

          Co-Chair, OASIS
            DITA Technical Committee 

        

          
"Where is the wisdom we have lost in knowledge?

          
Where is the knowledge we have lost in information?"

          
--T.S. Eliot 

        

      

    

    

    

    DITA Technical Committee Meeting Minutes: 22 March 2011

    

    Chaired by Don Day <> and Kristen
    Eberlein <>

    Minutes recorded by Don Day <>

     

    The DITA Technical Committee met on Tuesday, 29 March 2011 at
    08:00am PT for 45 minutes (late start due to phone # confusion).

    

    8:10-8:15 Roll call

    

        * Regrets: Eliot Kimber, Stan Doherty, Bruce Nevin 

        * Quorum was established.

    

    STANDING BUSINESS:

    

    Approve minutes from previous business meeting:

    

        *
    http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201103/msg00051.html
    (Bruce Nevin, Tue, 22 Mar 2011 11:28:21 -0500) 

        * Moved by Don, Seconded by Dick Hamilton

    

    Subcommittee/liaison reports:

    Bob Beims for SIDSC: Activity has been low lately; he is working to
    restart the SC work, which has several new members, had a new
    kickoff call last week. In a few calls, expects to see getting to
    new focus. One company wants to contribute their domain to the SC.
    Next phase is to interoperate data between companies.

    

    Kris suggested reordering the agenda; work on #3 first:

    

    3. Extensions to DITA filtering (Jonatan Lundin): 

    Jonatan briefed: Machine industry found not all attrs in DITA are
    applicable to MI.

    Subject Scheme came along, looked useful for controlling needed
    subject values.

    Could a single filter attr with a generic domain be used in place of
    domain-specific attributes?

    

    Michael: reviewed existing vs potential new input:

    @props was meant to be semantics-free, can be specialized for
    backwards compatibility for new domains, as well as binding new
    subject schemes.

    Spec is missing a way to bind vaues to a single attribute rather
    than specializing. Syntax is intended only for generalization.
    Syntax allows for round-tripping, but is painful for direct
    authoring. Hence specialization is a better authoring strategy. The
    proposal for 1.3 is to enable the generalized syntax to be directly
    authorable and controlled about through subject shceme in the way
    that specialized attributes are.

    

    Jonathan agreed with Michael's review and summary. Pointed out that
    the DITA values discussion doesn't cover filtering out topicrefs
    based on subject scheme classification.

    

    Michael: Rephrase: given that we have a way to bind subject
    definitions to filter attribute values, would it make sense to have
    subject values filtered by property values to have the same
    treatment as filtered attrs?  

    (noted that IBM is providing a single filtered interface for content
    coming from many parts of the company)

    Topicmeta for prolog data is another case needing the common
    handling.

    Michael thinks there are other cases (#2) for more complete
    architecture:

     * map with topicmeta

     * map with prolog

     * attrs in map or topic

     * subjectref in map only

    

    Don: Two issues? documentation on best practices across the board,
    and specific proposal?

    Michael: Yes, two technical issues: 

     1) complex filtering definitions within a single props attr
    governed by subject schemes, and 

     2) reconciled metadata schemes for filtering including topicmeta or
    prolog attributes in subjectref

    

    Michael explained current filtering logic based on semantics within
    the content, noted difficulties with general boolean logic.

    Issues are: Power to author vs power to reuse.

    Ways to increase expressability of ditaval file could help increase
    usability.

    

    Jonatan: Worth exploring, needs evaluated carefully. Cascading rules
    for conditional attributes is another complexity. 

    

    Michael: More issues for completeness (already noted):

     3) Would like to see more flexibility for the cascading (which is
    currently always additive). Need a way to declare when metadata is a
    blanket assertion vs a blanket default. Should apply for both
    processing and scope (branch variation) (this is on the list
    already)

     4) Separating various ditavals with scope (again, already in the
    list--brought up by Jeremy Griffith)

    

    *Actions:* Don, add the two new 1.3 items mentioned by Michael

    

    Kris: back to business agenda

    1. FAQ item about key resolution:

    Su-Laine: No new feedback, per Su-Laine. Looking for input on what a
    processor should display for an element with a keyref, assuming
    binding has been computed. Concern that what's displayed is
    undefined. What topicmeta elements should be managed by processor,
    what is the priority of topicmeta from other content with the keyref
    on it? Su-Laine is still uncomfortable that the write-up expresses
    the best interpretations--it might expose problems wiht the stated
    design. 

    Robert notes the described action is opposite of xref, Su-Laine
    asserts also not what DITA OT is doing.

    Kris: what could help us move forward most friutfully?

    Su-Laine: get Eliot to review more specifically. Kris suggested that
    Robert and Michael might help.

    *Action:* Michael and Robert and Eliot to review the material about
    “Key resolution for complex <topicmeta> content. 

    *Action for all* to review the material about “What is the
    interaction between key resolution or key binding and conditional
    processing?”. Plan to discuss next week

    

    2. Conditional processing before/after keyspace construction:

    No new review comments. Kris urges TC to stay enlightened, needs
    held for Eliot to be back on the call.

    

    4. DITA complexity:

    Not enough time to cover today. Back to forefront next week.

    *Action for all* to look at wiki page and two email messages in the
    agenda (Stan and Paul)--bottom of the email is germane to this
    thread.

    

    Kris: Any announcements or questions?

    

    Doug Morrison noted being at a recent HAT meeting where no one had
    heard of DITA. Kris asked him to record that observation in the wiki
    page.

    

    Kris asked Thilo to provide survey results for review next week.
    Next week is DITA NA. Don will chair, Kris will be out.

    

    Don noted end of hour; adjourned.

    

    ACTIONS:

    1. Don, add the two new 1.3 items mentioned by Michael

    2. Michael and Robert and Eliot to review the material about “Key
    resolution for complex <topicmeta> content:

    http://wiki.oasis-open.org/dita/Review-FAQ-#Item.233.3AKeyresolutionforcomplex.3Ctopicmeta.3Econtent.
    

    3. Action for all: review the material about “What is the
    interaction between key resolution or key binding and conditional
    processing?”:

    http://wiki.oasis-open.org/dita/FAQ-items#Q.Whatistheinteractionbetweenkeyresolutionorkeybindingandconditionalprocessing.3F
    . Plan to discuss next week

    4. Action for all: review the DITA Complexity wiki page
    (http://wiki.oasis-open.org/dita/DITA_Perceptions) and two email
    messages on today's agenda:

     * http://lists.oasis-open.org/archives/dita/201101/msg00051.html
    (Stan Doherty, Tue, 18 Jan 2011 11:28:35 -0500 -- recent e-mail on
    thread)

     *
    http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201102/msg00069.html
    (Paul Grosso, 22 Feb 2011 13:13:41 -0500 -- scroll down to bottom of
    e-mail)