Minutes of DITA TC 2022-01-18

[Eliot Kimber <ekimber@contrext.com>]

Minutes attached.

 

Cheers,

 

E.

 

--

Eliot Kimber

http://contrext.com

 

 

Minutes of DITA TC 2022-01-18

1. Approve minutes from 1/11. Motion to approve as submitted. Seconded by Scott Hudson
   - Carried by acclimation.
   
2. Agenda item 5 - Review of metadata elements

   - Editors still responding to review comments
   - Discussion of emerging questions
   
   Zoe: 
   
      - Concerned that she often abuses metadata elements or is not using them correctly.
      - v/r/m : Doesn't always fit what you need, have to abuse.
      - Is there an appropriate base for ad-hoc metadata? (Answer: <data>, <othermeta>)
      - Would like an architecture topic that says "it's OK to abuse these metadata elements".
      
   Kris:
   
      - Current elements definitely reflect IBM practice (and Eclipse implementation details [Eric])
      - Many large DITA implementations create their own metadata
      - Difficult to create a robust set of generic metadata elements across a large user base
      - Opinion: too late to do much now. Are there changes that are worth making?
      - Reworking metadata was an early 2.0 goal that nobody ended up pursuing.
      
   Robert:
   
      - Definitely reflects old IBM practice
      - Do we want to completely redo the metadata? 
   
   Eliot
     
      - Could move metadata elements to a domain but would have a big cost.
      
      
   - Question: why do some but not all metadata elements allow keyref?
   
     Robert: Originally intended to be links to information about the the thing mentioned in the value of the metadata item.
             Done in 1.0 timeframe and was not rethought in 1.2 when keys were added.
             
     Kris: Probably no value in adding @keyref where it is not used.
     
     
   - Question: Should we be mentioning the relationship of metadata elements to Dublic Core?
   
     Kris: Any idea why we mentioned Dublin Core?
     
     Robert: Dublin Core was a big deal and we wanted to play along. Now DC is not nearly as big as it was.
     
             Items that had not come from IBM's usage modeled Dublin Core. 
             
   - Question: Is there an interaction between elements that have same name as defined @props specializations?
   
     Kris: Editors removed earlier statements about interactions.
     
     Robert: Goal in 1.0 that there would be some relationship TBD, work was never done.
     
     Dawn: The elements definitely cause confusion with authors and has to be addressed in the training
      
   - Comment @content contains potentially translatable content. 
   
     Robert: <othermeta> came from DITA 1.0 and was intended to model the HTML <meta> element.
     
     Eliot: Existence of @translate-content argues for leaving @content as is because translation concerns have been addressed. 
        
     Kris: Gershon can choose to pursue this.
     
   - Question: Why are there no processing expectations for these elements?
   
     Kris: Can't specify any processing or rendering expectations for any of them as they are inherently processing specific.
     
     Zoe: Question came from general usage of spec as a user guide. Was looking for more information on "what is this for and how do I use it?"
     
     Robert: Just because it's there doesn't mean you need to use it, particularly true for metadata. 
     
     Kris: My approach with clients is to use minimum of metadata you need and keep it as simple as possible.
           Metadata authoring is expensive and error prone.
           
     Dawn: Agree--cost of metadata is high, have to justify the value. Requiring things often leads to bad data entry.
           Customize authoring or content to limit choices.
           There has to be a balance between no metadata and too much is part of the consulting art.
           
     Zoe: How much of spec needs to be a user guide or describe best practices?
     
     Kris: Spec is not a user guide and cannot define or describe best practices.
     
     Zoe: Agree upon reflection that the spec can only say "it's implementation dependent"
     
     Zoe: Children of prodinfo -- questions about those. 
     
     Kris: All elements within prodinfo now point to prodinfo reference topic. Added examples of all children.
           More we can do.
     
4. Agenda item 6: Review H -- Chunking opening 1/18 for 2 weeks

5. Agenda item 7: Status of review D

    Kris: Review comments almost completely addressed.      
    
    Kris: Proposing removing implications for <schemeref> as a way to extend subjectschemes. See email thread 
          (https://lists.oasis-open.org/archives/dita/202201/msg00022.html)
          
          Not sure how to say "We're removing any discussion of extending subjectschemes" but we need to do it.