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: 29 January 2008

Hi all,

Please review the pending votes for next week's meeting and discuss any issues on the list so we can vote on the proposals next week.


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

1.  #12038 - Acronym proposal updates
    Robert to upload amended proposal.

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: 29 January 2008

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


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

1.  #12038 - Acronym proposal updates
    Robert to upload amended proposal.


The DITA Technical Committee met on Tuesday, 29 January 2008 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/200801/msg00031.html (22 January 2008)

    Accepted by acclamation.

3.  Business:

    1.  ITEM: Proposals for Design Approval vote:
        * None

    2.  ITEM: Review prepared proposals:

        1.  ITEM: #12038 - Acronym proposal updates
            * http://lists.oasis-open.org/archives/dita/200801/msg00034.html
                * (based on Jan 28 Trans SC call)
            * http://lists.oasis-open.org/archives/dita-translation/200801/msg00020.html                        
                * minutes from yesterday's call (mislabeled in the subject line):
            Robert: I made some minor updates based on discussions yesterday.
            * Moved Spanish example to after the text describing the example 
              instead of before it.
            * Added a second example in Spanish to wmd so we now have an example
              of two different methods.
            * Added notes to remind spec authors how to explain some things, 
              * keyref - you can have multiple keyref values pointing to the same
                target. Processors must use target, not value in @keyref.
              * @keyref does not have to match the acronym.
            Don: We also need to delete the sentence that was formatting-related.
            JoAnn was concerned that we track the deletion of the sentence to be
            sure there are no undesirable side effects.
            Erik suggested we delete the comment and leave a draft comment so we
            can track where it was.
            Don proposed to change the document and that the amended proposal
            be placed for design approval next week.
            DECISION by acclamation to put #12038 up for design-approval vote 
            next week.
    3.  ITEM: Organization of the DITA Specification
        * http://lists.oasis-open.org/archives/dita/200801/msg00035.html  (review thread)
        * http://lists.oasis-open.org/archives/dita/200801/msg00039.html  (McRae on OASIS guidelines)
        Don read through Mary's clarification note.
        CK: Machine Industry viewpoint is that it makes more sense for combined 
        public review, since it's domains added to the main specs plus some 
        improvements to the main spec, so for us it is linked together.
        Therefore it is better if the MI spec part of the overall spec for 
        public review. For delivery we may have to think of separate packaging 
        of the various domains.
        DD: Mary is saying that whatever is part of the public review is part of 
        the spec that goes through the full review process.
        JO: Also there's a lot of effort in getting votes, so multiple votes 
        means much more effort and bother to solicit the votes.
        JO noted that RA's email was more about packaging than approval process.
        EK feels the individual specs should be clearly separate sections in 
        the spec.
        There is a challenge now that the shell DTDs include everything, 
        which means users have to cut away what they don't need. And with 1.2 
        it's going to grow much bigger. Therefore need to work out the challenge 
        of how to package the DTDs and also how to package the documentation for 
        those DTD packages.
        JO: There is a proposal on the table (see wiki) for breaking the spec up
        into modules (sub-packages) for each of the pieces so that users can
        manage them separately.
        JO suggested packaging the minimum DTDs, the maximum DTDs (for review 
        purposes of the spec) and a few other packages that would meet the needs 
        of a sizable user group (eg. publishing; software documentation and 
        perhaps learning).
        EK agreed that we should provide various packaging alternatives and if 
        the shells are set up to allow pluggable inclusion of domains that would 
        be good.
        DD: We see a need to describe scenarios on why we set up the DTD packages
        the way we do. Should these scenarios become part of the spec?
        EH: If users could generate new shells easily we would not need to 
        include any, but those tools are not there, so I suggest the tools should 
        mandate the most comprehensive shells that can be refined via constraints.
        Discussion on whether the shells need to be a normative part of the spec. 
        e.g. XSL-FO spec includes DTD and schemas that are not part of the spec; 
        they are just useful tools users can use if they like.
        Don asked whether anyone has concerns about making the DTD shells 
        informative from 1.2.
        ... in principle the 1.2 spec would specifically designate the shells as
        informative rather than normative.
        ... so we're asking for an editorial position here.
        Don suggested making a document on the wiki with editorial positions or 
        goals that will document these TC discussions. We don't need formal
        votes on them. 
        ACTION: DD to start a wiki document called "editorial notes" with the 
        first note: "modules are normative; shells are informative."

    4.  Ongoing: Discuss the 2-implementations rule for specializations under 
        revised Spec organization
        * Review--is this affected by the OASIS packaging guidelines for specs?
        DD: Is there any more to discuss on this point?
        JO: Last time we decided we need not 2 implementations, but 2 users using
        each of the components and then people can certify those components. 
        There was some disagreement between 2 users vs 2 implementations on the 
        last call.
        EK: 2 users still won't give you interoperability. Having said that, 
        if you have to wait for 2 complete implementations of everything we'll 
        wait a long time.        
        Out of time. Don asked to take this discussion to the list to try to 
        work out the 2-implementations rule and 2 users vs 2 implementations.
        --Out of time. Meeting adjourned.--

    5.  Ongoing: Review of "Items for discussion" list in the Frontpage
        * Review where we are at; what topics need more work.        

4.  Announcements/Opens

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