MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE

MHonArc v2.5.0b2 -->
















dita message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE




From: "Larsen, Seraphim L" <>
To: <>
Date: Tue, 7 Feb 2006 12:07:54 -0700






Title: MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE






MEETING MINUTES -- 07 February 2006 -- DITA TECHNICAL COMMITTEE
(Minutes taken by Seraphim Larsen <>)


Date:  Tuesday, 07 February 2006
Time:  08:00am - 09:00am PT


DITA Technical Committee website:  
    - Public:       http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
    - Members only: http://www.oasis-open.org/apps/org/workgroup/dita/
    - Wiki:         http://wiki.oasis-open.org/dita/


- Roll call
    - We have quorum
    - ACTION for Don and Seraphim to review membership guidelines,
      and clean up the membership list to make sure we can get
      quorum 


- Review/approve minutes from previous meeting:
    - http://lists.oasis-open.org/archives/dita/200601/msg00037.html (31 Jan 2006)
        - Don Day proposes to approve the minutes as read, Alan
          Houser seconds, no objections, approved by acclamation.


- News, events:
    - Translation liaison meeting report
        - JoAnn Hackos provided a summary -- 
            - There is considerable interest
                - to define best practices for authoring for
                  translation
                - to ensure that the various standards work together
                  effectively
            - Many people attended, from the localization service
              provider industry and people who participate on other
              standards committees
            - There was some discussion on inline elements, some of
              the potential issues around author control of the
              translate yes/no attribute
                - Most of this will be covered by "best practices"
            - There was optimism that they could produce a transform
              to go between XList and DITA pretty quickly
        - Don -- If we can get the right players together, we can
          make this an Open Source project
        - JoAnn -- Thanks Robert Anderson and Chris Wong for their
          help with this!
            - Chris provided some details of the discussion


- Resource: OASIS DITA Wiki  http://wiki.oasis-open.org/dita/FrontPage
    - Our previous work on items accepted for DITA 1.1 is here:
        - http://wiki.oasis-open.org/dita/AcceptedAndCandidate


- Resume review of "left off the list" and unnumbered proposals for
  1.1 scope (http://wiki.oasis-open.org/dita/OffTheList#preview)


    - "Recognizing DITA Documents"
        - SUMMARY:  Paul Prescod moves that the 1.1 specification
          should say that tools should support both .dita and .xml,
          but it is recommended as a best practice that .dita be
          used.
            - Michael Priestley -- Seconds
            - No objections -- Approved by acclamation.


        - DISCUSSION:
            - Paul Prescod (PP) -- One issue -- You can't recognize
              DITA documents in general until after you've
              identified the document type.  So, they're system
              first identifies the document type, and then decides
              whether it's DITA or not.  The biggest gap is actually
              in the DITA toolkit -- you need to be consistent
              within maps with the file extensions that you use.
                - Don Day (DD) -- The use of .dita is really a best
                  practice rather than a convention (as opposed to
                  using .xml).  Is this an item that needs to be put
                  on the list for integration into the
                  specification?  (That the recommended best
                  practice of using file extensions to identify file
                  types, be rolled into the specification.) Because
                  it's not in the specification, tool vendors are
                  having trouble with it.
                - PP -- Tools should support both standards.  The
                  spec should recommend .dita, we should be pushing
                  people that way.  It is certainly a toolkit issue,
                  but should also be addressed by the spec.  The
                  user community should prefer .dita.
                - DD -- It's not apparent when you are looking at
                  a list of XML files, it's not clear from the .xml
                  extension which ones belong to DITA.
                - PP -- Tools should support both extensions, but
                  .dita is preferred for usability reasons.  
                - MP -- We all agree that both .dita and .xml should
                  be supported in the tools.
                - Paul Prescod proposes that the 1.1 specification
                  should say that tools should support both .dita
                  and .xml, but it is recommended as a best practice
                  that .dita be used.
                    - Michael Priestley -- Seconds
                    - No objections -- Approved by acclamation.


    - Start of documenting DITA design principles (Paul Prescod) 
        - http://lists.oasis-open.org/archives/dita/200510/msg00005.html


        - SUMMARY:  It is decided to move the discussion to the Wiki
          -- this is not an issue for 1.1.


        - DISCUSSION:
            - MP proposes that PP and MP should collaborate on a new
              list (or updated list), and bring that back to the TC
              as a proposal.
                - MP -- It doesn't affect DITA or any current
                  implementations.
                - Don -- The Wiki is the best place for this kind of
                  documentation to start and to proceed.  It's
                  a good place to collaborate.  
                - Recommend moving the discussion to the Wiki --
                  this is not an issue for 1.1.


    - Module Registry proposal (Bruce Esrig) 
        - http://lists.oasis-open.org/archives/dita/200510/msg00097.html 


        - SUMMARY: Don Day moves to close this item as a 1.1
          specification item, and initiate an action item to put
          this on a future agenda.
            - Bruce Esrig seconds
            - No objections, approved by acclamation.


        - DISCUSSION:
            - Bruce -- The question is whether this is a DITA spec
              issue at all.  Should something be done to make sure
              the DITA namespace doesn't get cluttered with new
              specializations, especially since people will be
              addressing similar problems in different way?  That's
              the idea behind the module registry.
                - MP -- Having something more formal (a URL where
                  you are guaranteed to find a particular module)
                  allows you to build a DITA DTD to match
                  specialized content that you may come across, just
                  by refering to the Module Registry.  This could
                  even be automated.
                - Don -- Could this be an Open Source or commercial
                  tool that can handle this?
                - MP -- Yes, a tool could do that, but the
                  repository itself would need to be on OASIS.  
                - Don -- With all the issues already on our plate
                  for 1.1, and limited resources for completing the
                  1.1, should we postpone this till after 1.1 is
                    completed?
                    - MP -- There might be work for the TC to do,
                      but most of the work would fall on OASIS.
                        - The proposal is that we ask the OASIS
                          administration to set this up for us.
                        - PP -- It will still take a lot of our time
                          to tell them what the requirements are and
                          how it should be set up.  
                        - JoAnn -- Shouldn't we put this on Bruce's
                          area on dita.xml.org?
                        - Don -- That would meet about 80% of the
                          value.  Is it worth the additional 20% to
                          get the OASIS people to make this happen?
                        - Erik Hennum -- Would this work like the
                          Perl CPAN model?  
                        - MP -- That depends on where you keep the
                          .mod files
                        - Erik -- You'd prefer to pull plugins from
                          multiple sites.
                        - MP -- For base DITA, you've got the design
                          modules at OASIS, and the open-source
                          processing for it is all at sourceforge.
                          We'd want to continue that distinction for
                          specialization -- sourceforge for
                          processing, but the modules themselves at
                          OASIS?
                        - Don -- This could take a lot more
                          discussion -- to close on it for now,
                          we're trying to figure out what is in the
                          1.1 specification space for now.   Since
                            this isn't in the 1.1 specification
                            space, can we discuss it somewhere else?
                            Let's make this a future TC agenda item.
                        - Don Day moves to close this item as a 1.1
                          specification item, and initiate an action
                          item to put this on a future agenda.
                            - Bruce Esrig seconds
                            - No objections, approved by
                              acclamation.
                    
    - Clarification of Chunk attribute (Erik Hennum) 
        - http://lists.oasis-open.org/archives/dita/200511/msg00070.html 
        - PROPOSAL -- Don Day moves to include this item within the
          1.1 scope.
            - Paul Grosso seconds
            - No objections, approved by acclamation


    - Criteria for making distinction between general and
      industry-specific DTDs/schemas (future agenda discussion) 
        - Don -- Is this in the scope of 1.1, or is this an
          implementation issue?  It doesn't seem like
          a specification-level issue.  
        - No objections, so we'll drop this as a 1.1 issue and keep
          it for a future agenda.


    - Graphic (image) scaling improvements (Paul Grosso) 
        - http://lists.oasis-open.org/archives/dita/200601/msg00025.html
          (and following responses) 


        - SUMMARY:  Don proposes to accept Paul's recommendation as
          a 1.1 design issue.
                - Bruce Esrig seconds.
                - No objections, approved by acclamation


        - DISCUSSION:
            - Paul Grosso summarized the proposal.  We need to be
              able to scale images.  He has two specific
              recommendations, which are both backwards-compatible.
                - Recommendation #1:  Add the "scale" attribute to
                  the "image" element, and change the declared type
                  of the scale attribute to NMTOKEN.  Define the
                  allowable value space of the scale attribute to be
                  any unsigned integer.
                - Recommendation #2:  Augment the DITA spec to say
                  that the value space of the height and width
                  attributes on the image element is a length which
                  is a real number with an optional unit.  The
                  allowable units are pc, pt, px, in, cm, mm, em (an
                  omitted unit implies px).  This requires no change
                  to the DTDs/Schemas.


                - Don -- Is this 1.1 scope?
                    - The proposal is to introduce scale as an image
                      attribute, and to broaden the range of values
                      you can use for height, width, and scale.
                    - Table uses "scale" for font scaling.  Graphics
                      would need to use "scale" for image size
                      scaling.
                    - Several people chimed in, that yes, this is an
                      issue for their users.
                        - Bruce Esrig, for example, sees a need for
                          this issue to be addressed.
                - Don proposes to accept Paul's recommendation as
                  a 1.1 design issue.
                    - Bruce Esrig seconds.
                    - No objections, approved by acclamation


    - Michael Priestly raised a new point whether we should add
      a namespace for DITA to the 1.1 spec -- 
        - ACTION for Michael to start discussion on the list.
        - ACTION for Don to include this on a future agenda.


<end>




___________________________________________________________ 
Seraphim Larsen                       CIG Operations / TPPE 
Senior Technical Writer                   Intel Corporation 
(480) 552-6504                                 Chandler, AZ 
The content of this message is my personal opinion only. 
Although I am an employee of Intel, the statements I make 
here in no way represent Intel's position on the issue, nor 
am I authorized to speak on behalf of Intel on this matter. 
___________________________________________________________ 















[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]