Minutes of Meeting May 4th, 2015

[Aaron Rothschild <a.rothschild@finkenwerk.de>]

Here are the minutes of our last meeting on May 4th, 2015.
Best regards, Aaron.





Roll call:
- Michael Priestley
- Kris Eberlein
- Don Day
- Carlos Evia
- Frederic Giers
- John Hunt
- Marc Giffin
- Sissy Closs
Regrets: 
- Noz Urbina
Assignment of minutes: Aaron Rothschild

# Recap of Content Management Conference
Michael et.al.:
- had a meeting of the SC, birds of a feather gathering, why lightweight dita, separate table on learning and training caused fragmentation
- good discussion
- definitely strong interest to get out of the door as fast as possible as simple as possible
- ditching domain specific specialization, instead let this happen at it's own pace, not part of the spec deliverable
- we still want some number of specializations as proof of concept of the core architecture to prove we can develop useful applications, but is not a prereq.
- lowers the bar, allows for faster delivery, 
- not push for fast standardization, but for quick start of public review and possibly extended review period, let vendors and users try out things
- whether to keep the name light-weight dita, including titles without the term DITA to eliminate baggage.
- at the table: in favour of keeping DITA in the name
- one idea: if we are going to release a minimal spec, that could link to separate pages for the analysis and validation of separate domains. Those could showcase "DITA or not" depending on the applicability for the domain, e.g. "marketing". They could themselves be any thing they want, e.g. "intelligent content for marketing"
- joke name: finch (fully intelligent content...)
- Don: likes the idea of having the domains call themselves according to their needs, possibly without the term DITA.
- Michael: content task and reference needs to be available as a proof of concept
- "terrible troika": Mark Baker, "full of misunderstandings": http://everypageispageone.com/2012/07/28/the-tyranny-of-the-terrible-troika-rethinking-concept-task-and-reference/

presentation on lightweight dita
Carlos, Lou Eye, Michael: 
- JSON DITA mapping for a case study specialization and markdown mapping, brief intro/overview how it can become interesting in an enterprise environment
- pretty good response
- 350 people for conference, similar to previous year

Sissy, Michael:
- draft document type to provide a starting point, a good example: recreate task as a specialization of lightweight topic
- created domains for each sections, but with structural class attributes for back compatibility
- context, prereq, postreq etc.
- steps were tricky because specialization to lists
- steps-informal (section): lightweight dita task will only support steps-informal
- upgrade to full task is possible (with the exception of steps-informal)
- integration of light-weight and full dita inside a map is possible and intended
- unknown: lightweight dita-ot? development of DITA-OT doesn't reply to sub committee
- Don: opportunity to build tools with support for domain specific applications of lightweight dita
- Don: DITA-OT should absorb lightweight dita topics with grace

John Hunt, learning and training:
- learning and training question type attracted highest interest
- less interest on learning specific topic types, map types, 
- SAP is biggest use case
- fantastic opportunity to take a fresh look at the initial intentions and make use of the light-weight approach
- elements: a lot revolves around clearly stated objectives. Of all the elements in use [...]. Others are simple specializations of sections. There is a list of other content types: lesson plans, exercices etc. as well as authoring approaches, LaTeX (Carlos Evia). 
- Quiz and Question types has most activity

Michael:
- proof of concept based on question type ?
- Kris: medical content as an epiphany for using lightweight dita
- Michael: want to reuse draft comment from the base
- (1) simple method for adding and subtracting elements from the full dita model, 
- (2) do we need to allow domain specialization for blocks, or would structural specialization be enough? 
- Kris: coding much easier with the restriction
- Michael: content model has complexity due to allowing a level of redirection by allowing to specialize lists, blocks etc.
- Michael: with struct. spec., reuse section specialization across topic types without using domains
- lists: have to explicitly specify where it's allowed instead of allowing it everywhere. You may specialize blocks but you have to say where they go.
- Don: web community: ARIA attribute what something is for accessibility, schema.org




# Status of the different Domains
- Don: training
- Stan: software, he presented at the conference stuff that is relevant
- Kris: medical
- Noz: marketing, has joined the SC, has sent preliminary email to find meeting time
- Sissy: machine industry, would like to make example for real world implementation



# Minimal Viable Spec
- Michael: Anyone willing to work on "Draft Doc Type"?
- allows domain specialization for blocks, 
- unsure if this is the right approach
- Carlos: 2nd week of June more time
- Mark Giffin: topic map, specialized section types for equivalent of reference
- goal: trimmed down version of map and topic
- Avoid domain specialization for this first sample
- allow spec at phrase level