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: DITA Technical Committee Meeting Minutes: 20 November 2007

Please be sure to review proposals that are pending design approval vote and send comments to the list ahead of next week's meeting.


The following items will be voted upon at the next TC meeting:

1.  #12026 - Enhance the Glossary specialization (Warburton, Hennum, et al.)
    * http://www.oasis-open.org/committees/download.php/26130/IssueGlossary12026.html

Gershon L Joseph
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd. 
Secretary, OASIS DITA Technical Committee
Secretary, OASIS DITA Translation Subcommittee
Member, OASIS DocBook Technical Committee
+972-8-974-1569 (direct)
+972-57-314-1170 (mobile)

DITA Technical Committee Meeting Minutes: 20 November 2007

Chaired by Don Day <dond@us.ibm.com>
Recorded by Gershon Joseph <gershon@tech-tav.com>


The following items will be voted upon at the next TC meeting:

1.  #12026 - Enhance the Glossary specialization (Warburton, Hennum, et al.)
    * http://www.oasis-open.org/committees/download.php/26130/IssueGlossary12026.html


The DITA Technical Committee met on Tuesday, 20 November 2007 at 08:00am PT for
60 minutes.

1.  Roll call

    We have quorum.

2.  Approve minutes from previous business meeting: 
    * http://lists.oasis-open.org/archives/dita/200711/msg00020.html (13 November 2007)
    * http://lists.oasis-open.org/archives/dita/200711/msg00023.html (amendment)

    Accepted by acclamation.

3.  Business:

    1.  ITEM: Proposals for Design Approval vote:

        None this week

    2.  ITEM: Review prepared proposals:

        1.  Check status of ITEM: #12007 - Indirect reference/keyref proposal (Ogden et al.)
            * http://lists.oasis-open.org/archives/dita/200710/msg00053.html
            * Most recent comments--this and earlier
              * http://lists.oasis-open.org/archives/dita/200710/msg00075.html 

            Jeff not on call this week.
            Michael says it's in good shape.

            ACTION: MP to contact Jeff to set up phone call for next week.
            Revisit next week.

        2.  ITEM: #12011 - Generic Task Type (Houser)
            * http://lists.oasis-open.org/archives/dita/200711/msg00005.html
            * Most recent comment:
              * http://lists.oasis-open.org/archives/dita/200711/msg00007.html (Houser) 

            Alan: I've been struggling on this one because the possible solutions 
            have ramifications. We'd need to change the content model for <task>, 
            which would result in migration issues. The other approach (the one 
            originally proposed) is to create another task type. I feel this 
            would breed confusion; the two info types would overlap. A third 
            approach is leveraging the new constraints mechanism to create a 
            more generic task and step model and allow constrainers to constrain 
            it. I have not thought this approach through yet and would appreciate 
            input from TC members about possible ramifications.

            EH is in favor of opening up task and then constraining it to get the 
            more constrained one.

            MP: There is a limit as to how much we can achieve via constraints. 
            For example, the use case to allow text directly in <step> would not 
            be supported via the constraints approach. If we relax <step> to 
            allow text, we'd loose all the info model on the base step and allow 
            any number or order of cmd, and other elements. We would be giving up 
            sequence and number control. Suggested <simplestep> (suggestions for 
            a better name are welcome) as an option to retain the current content 
            model and also provide a solution for the use cases.

            EH: The more general version could make available additional elements 
            that could be constrained away (e.g. simplestep).

            Discussion on how best to handle multiple steps; how best to preserve 
            the current content model structure.

            Summary: We're talking about expanding the existing task model and 
            then having a second DTD to constrain it back to the current task model.

            ACTION: AH to continue working on the proposal.

            Revisit next week.

        3.  Hennum comment on following updates:
            * http://lists.oasis-open.org/archives/dita/200711/msg00028.html
            No major changes to either proposal.

            * ITEM #12026 - Enhance the Glossary specialization (Warburton, Hennum, et al.)
              * http://www.oasis-open.org/committees/download.php/26130/IssueGlossary12026.html (updated)

            DECISION to put this proposal to design approval vote next week.

            EH requested everyone to look over the proposal.

            * ITEM #12047 - add convenience elements for composing maps that set attribute defaults (Hennum, Kimber, et al.)
              * http://www.oasis-open.org/committees/download.php/26129/IssueMapConveniences12047.html 

            EH: The TC members are requested to review this item.

            ACTION: TC members are requested to comment on this proposal on-list.

            Revisit next week.

        4.  Updated ITEM #12035 - Generic collation element (Pickett)
            * http://lists.oasis-open.org/archives/dita/200711/msg00026.html

            MP reminded the TC that the proposal for a generic universal 
            collation element was deemed to be too extreme considering
            DITA does not support collation at this time. The TC had previously 
            asked DP to come back with a new proposal to split off topic 
            collation for DITA 1.2 and save the rest of her proposal for a later 
            DITA release.

            The TC is still waiting for a revised proposal from DP that meets the 
            requirements the TC requested (topic only for now). The current
            proposal covers the entire spectrum that was rejected by the TC for 
            DITA 1.2 scope.

            ACTION: Don to contact DP to enquire why the disposition and the 
            requirements document is not addressed in her proposal.

            Revisit after DP has responded to Don's request for clarification.

    3.  ITEM: Discussion on Controlled values, #collection-type enumerations and glossaries
        * http://lists.oasis-open.org/archives/dita/200711/msg00024.html (Pickett)
        * http://lists.oasis-open.org/archives/dita/200711/msg00029.html (Hennum reply) 

        EH: DP wants to address the issue of identifying a list that's collatable. 
        Currently she is using @outputclass because she didn't want to specialize.

        The contrary perspective is it's more serious to make processing expectations
        extensible rather than making the core attributes extensible.

        DP wants to be able to extend the values in any enumeration.

        Discussion on how controlled values addresses this issue. e.g. glossary 
        part of speech should be an extensible enumeration. The Learning SC also 
        has a number or enumerations that should be handled that way. Also note 
        type (Machine Industry SC). DP would like to extend this to collection-type. 
        Or should we replace collection-type?

        CK clarified that we are not opening up note, we are just completing the 
        list of note types. We don't want to open it up (only to make the 
        available list of values to include all the ANSI values that are currently 

        EH: If we agree to the keys and controlled values proposals, then the 
        question is how many or which enumerations do we bring in? Maybe all?

        MP suggested we should get a list of all enumerations so we can decide. 
        We're hitting scope creep; and how quickly can vendors cope with the 
        controlled values processing?

        Discussion on how much of a pain this would be for the tools (XML 
        editors). The TC noted we must get feedback from the tool vendors before 
        making a decision on how quickly to migrate enumerations into controlled 

        ACTION: EH to send a message to the list listing the enumerations and 
        soliciting vendor input.

    4.  ITEM: URI Scheme for TC Subcommittees (Sirois)
        * http://lists.oasis-open.org/archives/dita/200710/msg00000.html
        * Amended design patter, as requested last week:
          * http://lists.oasis-open.org/archives/dita/200711/msg00032.html (Sirois) 
        * Is this ready for adoption/recommendation for specializers? How formal?

        Don: How do we communicate this as a best practice for adopters?

        EH clarified: The issue is how do SC specializations label their work as 
        work of the SC. It's not for non-OASIS specializers.

        Don: Is it a recommendation or design pattern for the SCs to use?

        Robin: For naming conventions, we've found that recommendation or 
        guidelines are best.

        DECISION: The TC accepted ES's guidelines for URI naming conventions of 
        contributed work.

--Out of time. Meeting adjourned.--

    5.  ITEM: Request approval of Translation SC paper: (Pass today for expected update)
        * Best Practice for Using the DITA Conref attribute for Translation 

    6.  ITEM: Review of "Items for discussion" list in the Frontpage
        * How much flexibility for specializers?

4.  Announcements/Opens

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]