| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 7 June 2016 uploaded
- From: Nancy Harrison<firstname.lastname@example.org>
- To: email@example.com
- Date: Mon, 13 Jun 2016 23:38:31 -0700 (PDT)
1. Michael will post a link to the slideshare of the webinar. and will try to get the webinar itself made available to TC members (IP issues with CIDM)
2. Kris will come up with a timeline for errata, so we can deliver it in the fall
3. Robert will add @copy-to to list of removal items in 2.0
4. Stan will add issue of domains in various places to list of proposed white papers
Minutes of the OASIS DITA TC
Tuesday, 7 June 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
Regrets: Eric Sirois
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201606/msg00002.html (Nancy Harrison, for 24 May 2016)
Proposed by Kris, seconded by Bob, approved by TC
Lightweight DITA (LD)
Michael; we've got a basic model; it's been tested for marketing, we drafted a specialization model based on a topic model; with a template-based spec., we just need to create a template & modify it a bit, then create schemas. We do specializations by conrefing, rather than using doc shells; we need to test that and need to get the DITA ->Markdown mapping. We can do LD without XML. We had an LD track at the April DITA conference; we showed a model that worked, the presentation got a good rating and we were invited back for a webinar. People coming to LD for different reasons; ~50% tech writers, also training developers and marketing writers who are currently using DITA for more areas than just techcomm.
3 main reasons for interest in LD; 1) desire for non-XML authoring, 2) desire for easier authoring, 3) need for cross-silo sharing.
Kris; any thoughts about when LD might move from SC to TC? When might we start moving this thru the OASIS process?
Michael; we'd like to get an actual spec written to bring to TC; what do you think?
Kris; that's the right way to go; what about timeline?
Michael; it's mainly a resource issue; right now we're getting specialization model coded; once that's done, then HTML5 and Markdown mappings have to be done, then it's 'just' writing. Hoping to have draft by end of summer.
Kris; any assistance you're looking for from TC?
Michael; if TC folks can take a look at the slideshare from the webinar... There's a question as to, for HTML5 mapping, whether to use custom elements as well as attributes; we'd welcome expert input on that.
ActionItem; Michael will post a link to the slideshare of the webinar. and will try to get the webinar itself made available to TC members (IP issues with CIDM)
1. Action items
10 May 2016:
Robert and Eliot: Schedule meeting to start work on content model generation (Language Reference topics)
[not yet] - will meet next week
Bob and Nancy: Schedule meeting to start work on builds and style sheet changes needed for 1.3 errata; include Kris
[will meet next week]
17 May 2016:
Stan and Keith: Investigate use of Agile among standards organization (COMPLETED?)
Bob and Nancy: Examine template for DITA 1.3 errata document
[both have done individual look at it, will meet next week]
24 May 2016:
Robert: Add ux-window item to errata page (COMPLETED)
Robert: Add item about xref to items outside of map to DITA 2.0 Wiki (COMPLETED)
Kris and Robert: Compile list of deprecated or "reserved for future use" items (COMPLETED)
New members: None
3. Continuing item: DITA 1.3 errata
Editors: Robert Anderson and Kris Eberlein
Style sheets: Bob Thomas
Build: Nancy Harrison
Reviews: Joe Storbeck
SEO: Keith Schengli-Roberts
Set up @rev for errata; work errata items related to source (Completed to date)
Catalog files (Completed)
Robert; fyi, catalogs are wrong in the toolkit (taken from OASIS); but 2 should be brought up. For 1.2, we had a generic and a version-specific identifier. But the version-agnostic labels for 2 modules changed between 1.2 and 1.3; that's a bug we should fix in the errata. Also, in 1.2 we shipped 3 versions for every module; generic, 1.2, and 1.x; at 1.3, we dropped the 1.x versions; so if anyone used them, it's broken
Eliot; my fault for overlooking that, but fairly easy to fix in the catalog generation
Robert; pretty straightforward fix
Kris; what's your recommendation, to fix both?
Robert; yes, I'll add it to the errata page, and an explanation to the TC.
Correct content model topics
Search engine optimization
Template from TC Admin: https://lists.oasis-open.org/archives/dita/201605/msg00017.html
[covered in action items]
ActionItem; Kris will come up with a timeline for errata, so we can deliver it in the fall
4. Continuing item: Work on committee notes
Update to "Why Three Editions"
"Upgrading to a new version of DITA" (was "Upgrading to DITA 1.3")
Template from TC Admin: https://lists.oasis-open.org/archives/dita/201605/msg00008.html
Nancy; working group has met twice; Kris was going to come up with a set of topics in SVN for rest of folks to look at and fill in as appropriate.
Amber; the meetings provided good discussion; we went over what the paper should cover, and what it should not...
5. New item: Deprecating @copy-to
https://lists.oasis-open.org/archives/dita/201605/msg00047.html (Nitchie, 25 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00048.html (Kimber, 25 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00049.html (Nitchie, 25 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00050.html (Kimber, 25 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00051.html (Tivy, 25 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00054.html (Kimber, 26 May 2016)
https://lists.oasis-open.org/archives/dita/201605/msg00061.html (Kimber, 31 May 2016)
Chris; just fyi, I have very little experience working with the OT, but @copy-to has been a mystery to me. I don't think DITA requires @copy-to to work the way the OT has it work.
an output file per topic ref, rather than one-to-one topic per topic
There are multiple valid use cases:
1. [laid out in spec] provide a specific diff name for a particular instance of a topic.
2. [not covered in spec, but important] provide a hint to processor for an addressable URI for the output topic being generated;
I'm not sure @copy-to is the best way to do either; I think since 1.2, the key mechanism provides a better way of doing both of these things.
Eliot; now that we have keys, they give a more complete mechanism for associating names with topics, for whatever purpose. I think its functionality has been entirely supplanted by keys.
Robert; I'm ambivalent; @copy-to came about because of needing a stable output target; rationale was 'another name for the output chunk' but reasoning was also 'spec can't care about such things', so wording was changed in the spec.
Eliot; because you can put multiple keys on a single topicref, you may have to choose one, inserts a bit of additional complexity, but it's still useful.
Robert; but it should be up to implementations to decide, what to call the copy...
Eliot; authors need to control output names, but the way to do that is processor-dependent, as long as DITA gives you the information you need.
Stan; I like the proposal to use keys instead of @copy-to; but if we deprecate it at 2.0, there are plenty of companies that have never moved to keys, and we would be forcing them to do so.
Chris; maybe another specialization of the base @'s could do that.
Jim; my approach is to go with a base addressing mechanism, would require people to use @scope but not keys...
Don; in a dynamic processing scenario, want to be able to designate 'slug' an externally defined name to use with a topic.
Eliot; we have a number of options for creating that.
Chris; in a dynamic system, you could have any number of names.
Kris; we have many ways of doing that with our current system. Does anyone use copy-to?
Robert; it's in use around IBM, though not heavy use. So do we deprecaete it or remove it?
Kris; to rephrase that, do we want to remove it in 2.0? (i.e., deprecate now, remove it in 2.0) We should put out a list of to-be-removed items asap
ActionItem; Robert will add @copy-to to list of removal items in 2.0
6. New item: Domain elements in map metadata
https://lists.oasis-open.org/archives/dita/201605/msg00055.html (Magliery, 27 May 2016)
Tom; I found inconsistencies between domains included in various metadata items. I don't know whuy that is, or if it should be that way... Any thoughts? For one thing, the markup and xmlmention domains seem to be in everything.
Robert; we had discussions over what domains were appropriate and where; we put the domains in maps so that if you have metadata in map, it's the same is it would be in a topic. As to where some are allowed; domain mechanism is built on base elements, and all xmlmention elements are based on keyword, so they're allowed everywhere keywords are allowed. Other domain elements are based on ph, so they're not allowed in as many places.
Tom; that may explain my confusion; I'm just glad to know that someone paid attention, and it's not as random as it looks...
Tom; given DITA complexity complaints, maybe we could give this some thought in 2.0 and make it look more consistent (e.g. no apiname in metadata), So if we can clean it up , that would be great, but it might not be doable.
Kris; not in a way that doesn't cause massive disruption.
Deb; it seems like a good white paper subject for the Adoption TC
Stan; good idea; I'll add it to list of needed white papers.
Don; I wrote something up on this, it must be in Kavi somewhere...
Kris; Don, please look for it.
[issue closed for now]
11:59 PM ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]