| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 23 Febuary 2016 uploaded
- From: Nancy Harrison<firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 23 Feb 2016 09:31:08 -0800 (PST)
1. Tom will add the typo he found to the 1.3 errata list
2. Kris will look at the OASIS process around errata for next week.
3. Kris will have agenda item for next week on potential topics for dita.xml.org around community best practices and things we want to engage with larger community on. will send same thing to DITA TC members to get us thinking about that item.
4. All TC members need to review Oasis guidelines for writing conformance clauses.
5. Kris will find out what we need to do about opening an OASIS admin request to get an open source repository set up for Eliot's tooling project.
Minutes of the OASIS DITA TC
Tuesday, 23 February 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
Regrets: Bob Thomas
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201602/msg00036.html (Nancy Harrison, for 16 February 2016)
Proposed by Kris, seconded by Dick, approved by TC
1. Action items
26 January 2015
Michael: Decision about Lightweight DITA open repository
[hold till Michael is on call]
16 February 2016
Robert: Make sure that call-in number is functional
[completed, since call worked this morning]
Kris: Talk to Chet about difficulties finding DITA 1.3 spec through Google search (completed)
2. Continuing item: Tentative DITA TC agenda for 2016:
Reflections on DITA 1.0-1.3
Continued work on TAB comments:
Normative and non-normative wording
Hyperlinks for all element and attribute mentions
Conformance statement (will handle as part of item below)
Focus on conformance statement and new OASIS guidelines
DITA 2.0 planning
DITA 1.3 errata planning
OASIS open repositories
Interoperability demo, perhaps at tcworld 2016
Upgrade DITA-OT plug-ins to work with DITA-OT 2.2.2 or later
[oon agenda as a reminder]
3. Scheduling subcommittee and liaison reports for the next few months
April 12: Report back from CMS/DITA NA 2016
Kris; is Help SC still active?
Stan; Help SC isn't currently active, but I'll defer to Don; is there a role for the Help SC wrt next-generation help?
Don; I have some questions, but don't know if it's worth convening the Help SC on, or just meeting together with you and then regenerating the SC at some point.
Kris; I'll put the Help SC on the inactive list for 6 months; if in 6 mos we don't have any changes, we can close it then.
Kris; can Adoption/TechComm SC report on Mar 1st?
Stan, Joann; Mar 1st is fine.
Kris; OK, and Lightweuight DITA for 5/3, reserve 4/12 for report on CMS/DITA NA 2016
Joann; btw, wrt experts session on 4/6; everyone on TC is welcome to participate as an expert.
4. Continuing item: How to move the DITA 1.3 spec up in Google rankings
https://lists.oasis-open.org/archives/dita/201602/msg00045.html (Chet Ensign, 18 February 2016)
Kris; had a long call w/Chet about our discussion of feedback on process, plus this topic.
If you search on 'dita d1.3' you get the spec, but no one would ever think to do that.
So how can we improve this while OASIS is working on it?
Keith; for those of us who have blogs, we can link to it.
Kris; and wrt what should be linked to, I think the best thing is the Part 0 overview, which has links to everything else (i.e. Parts 1-3).
Keith, when it comes to deep linking, what do folks here recommend? If I do an article on linking, e.g., should i link to the a topic in Part 2 (technical content) or Part 3 (all-inclusive) release?
Robert; I've been linking to the least specific version of the spec, so Part 1 (base) if it exists there, only Part 2 or Part 3 if they need to go there.
Chris; that's what I do as well.
Kris; let's go on record as supporting that practice for deep linking; send folks to the least specific (smallest) version; ingeneral, link to Base version for architectural stuff; for links to info about a specific eleement, ;ink to the smallest package that includes it. Also, we may want to add a richer set of metadata to the spec that includes keywords, to generate metaadata in the HTML version.
5. New item: That first car ding
https://lists.oasis-open.org/archives/dita/201602/msg00043.html (Magliery, 17 February 2016)
Tom; I found a typo in the spec.
ActionItem; Tom will add this to the errata list
6. DITA 1.3 errata planning
Wiki page: https://wiki.oasis-open.org/dita/DITA_1.3_Errata
Kris; I'll look at the OASIS process around errata for next week. We almost certainly will want to do one. We'll need a release manager for this.
Nancy; I might be willing, but depends on timing; when would we be putting this out?
Kris; we'll know more when we discuss it next week.
ActionItem; Kris will look at the OASIS process around errata for next week.
7. Continued item: How should the spec handle statements about rendering expectations?
https://lists.oasis-open.org/archives/dita/201602/msg00006.html (Eberlein, 9 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00008.html (Kimber, 9 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00010.html (Day, 9 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00022.html (Eberlein, 16 February 2016)
New e-mail: DocBook Conformance Statement and rendering expectations
https://lists.oasis-open.org/archives/dita/201602/msg00037.html (Hamilton, 16 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00038.html (Anderson, 16 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00039.html (Magliery, 16 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00040.html (Anderson, 16 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00041.html (Kimber, 16 February 2016)
Dick; looked at DocBook spec to seee what we do for this; in DocBook, with each element description, there's a section called 'processing expectations'; it's not written as 'processors MUST...' , but as 'you should expect 'elementX' to be rendered as a block / inline, etc.' So elements give guidance for authors, rather than providing processing requirements wrt prrocessors.
Kris; so DocBook can't help us by way of conformance statements, but does have good example for 'processing expectations'
Dick; it's written as advice to the person using the element, rather than to the implementer.
Kris; so it's very different from what we're considering.
Robert; it could be nice if there's a common section like 'processing expectations', but it could also be overwhelming if there are a lot of them. If there only need to be a few of them, we could put them in only if there were something there, and just leave them out otherwise. But if there are a lot of them, then the section needs to be there for all elements, with 'none' if that's the case.
Eliot; it's important to have non-normative guidance where appropriate in langref entry, either inline or in separate doc.
Dick; we might find that there's more rendering info than you might guess; I think the majority of elements would turn out to have something, not 'none.'
Kris; we know there's a lot of it in the spec; this discussion was sparked by the realization that there's a lot, and it would be useful if it was consolidated. Are we ready for volunteers to do some prototyping? Robert, would you do a protyping exercise?
Robert; depends on what you want; I could mock up a template for possible new section.
Eliot; I'd like to contribute to that as well, though I can't do anything for next 3-4 weeks.
Don; if we're looking for content, might we use dita.xml.org?
Kris; right now, I think this is internal to the TC. I don't think it has to do with community best practices, though I'm sure we could come up with other adjunct topics down the road.
ActionItem: Kris will have agenda item for next week on potential topics for dita.xml.org around community best practices and things we want to engage with larger community on; will send same thing to DITA TC members to get us thinking about that item.
8. Continued item: TAB comments about normative and non-normative wording
See summary in https://lists.oasis-open.org/archives/dita/201508/msg00074.html ; search for "Normative and non-normative wording"
Seven TAB comments:
Keyword Guidelines for OASIS Specifications and Standards
TAB-approved document, 2014-02-21
[this is being considered together with #9]
9. Continued: Need for work on conformance statement for future versions of the spec
Overview (Robert Anderson)
See summary in https://lists.oasis-open.org/archives/dita/201508/msg00074.html ; search for Conformance
[OASIS] Guidelines to Writing Conformance Clauses:
Reviewed and revised on 25 April 2014; not yet approved
Kris; we ended last week's call with a discussion of what we need to do with conformance statements going forward.
Robert; I'm not sure what more to discuss wrt last week's discussion. The next step is to mock up something we could work with. I don't think we're close to being able to write a conformance clause, but we're far enough along to think about it.
Kris; I'd like all TC members to take a look at the OASIS guidelines (above) for writing conformance clauses; this was reviewed/revised in April 2014, but it's not approved as yet, so it's a moving target. But this is what they were keeping in mind when they made the TAB comments on 1.3.
ActionItem; all TC members review those guidelines.
10. Continuing item: DITA TC and open source GitHub projects
https://lists.oasis-open.org/archives/dita/201601/msg00010.html (Eberlein, 5 January 2016)
https://lists.oasis-open.org/archives/dita/201601/msg00011.html (Eberlein, 5 January 2016)
https://lists.oasis-open.org/archives/dita/201601/msg00040.html (Kimber, 12 January 2016)
Kris; we have a proposal from Eliot (above) around his tooling project. Eliot, are you ready to have us approve a motion to ask OASIS to set that project up?
Eliot moved that TC ask OASIS to move forward on creating an open repository for his tooling project.
Motion seconded by Stan, no objections, approved by TC.
ActionItem; Kris will find out what we need to do about opening an OASIS admin request to get this done.
11. Continuing item: Time for a reflection on DITA 1.0-DITA 1.3
https://lists.oasis-open.org/archives/dita/201601/msg00036.html (Eberlein, 12 January 2016)
Kris; is there anything we should be considering wrt to this in moving forward this year? One item I have is a request that in the future we have more than one person responsible for doing the official builds, and that at least one of the responsible people be neither the chair or a spec editor.
Eliot; there's no reason why building shouldn't be completely automatic based on checkin tags.
Kris; that would be great; we should clean up our ad-hoc build processes and dovetail more clearly with OASIS file naming requirements. If we update our scripts to meet their name conventions, how likely would they be to then change their rules? Chet told me the OASIS rules have been stable for at least 2 years.
Robert; so as long as we gt the release out in 2 years, we're fine. :-)
Kris; we need to get this on the agenda for next week; it's past due time to automate the build process. We've already done that for the 1.3 committee note (it's based on DITA-OT 2.x), but not for the spec PDF. Eliot, we'll put you on the spot to help with build automation?
Eliot; as you should...
11:45 PM ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]