| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 16 Febuary 2016 uploaded
- From: Nancy Harrison<email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 16 Feb 2016 09:38:16 -0800 (PST)
1. Robert will resolve the DITA call host access code issue
2. Kris will talk to Chet about what OASIS can do to help make spec more findable on Google.
Minutes of the OASIS DITA TC
Tuesday, 16 February 2016
Recorded by Nancy Harrison
link to agenda for this meeting:
[call started 15 mins after hour due to access code issues]
Regrets: Tom Magliery
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201602/msg00004.html (Nancy Harrison, for 09 February 2016)
https://lists.oasis-open.org/archives/dita/201602/msg00009.html (Correct by Eliot Kimber, 09 February 2016)
Proposed by Kris, seconded by Scott, approved by TC
1. Action items
26 January 2015
Michael: Decision about Lightweight DITA open repository
[Michael not present on call]
09 February 2016
Eliot: Create trunk dir in SVN (COMPLETED)
ActionItem; Robert will resolve the DITA call host access code issue.
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
[for info going forward]
3. Attendance at CMS/DITA NA 2016 (Eberlein)
Who will be there?
Do we need to cancel TC meeting for 5 April 2016?
TC dinner on 5 April 2016; volunteer to organize?
- attending: Kris, Nancy, Robert, Keith, Eliot, Bob, Chris, Michael, Stan, Joann (and probably Tom)
- April 5th DITA TC mtg cancelled due to most of TC being at conference
- Monday eve. TC dinner; Nancy will organize
4. New item: How to move the DITA 1.3 spec up in Google rankings
Kris; as a first step, all web pages connected to TC members should be linking to the spec.
Keith; question. which spec version should we link to?
Nancy; should we link to the committee note instead?
Eliot; seems like a good iea
Keith; but it leads to indirection, which isn't good. Want users to get a one-click resolution, not have to click/search/click.
Kris; maybe the OASIS 'overview' page is the right one...
Keith; but if we're linking to a specific piece, it has to be in a specific version.
Kris; depending on the kind of material, you could go to 1, 2 , or 3 places. but in any case, from Google, you'll go to various places, but not to the OASIS links. Maybe we should ask OASIS how to make it findable; they made us use this structure... In the meantime, we can just keep this item open on our agenda.
Joann; is the spec on dita.xml.org?
Kris; no, a pointer to it is on dita.xml.org
ActionItem; Kris will talk to Chet about what OASIS can do to help make spec more findable on Google.
5. 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
6. 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)
Kris; we have very specific terms, and no rendering is mandatory. So MUST/MUST NOT are not options for describing rendering, only SHOULD/SHOULD NOT, etc. Some topics should have normative statements but don't; some have statements dating back to DITA 1.0 that are now meaningless. How can we make these rendering expectation items be easy for implementors of processors to find?
Eliot; I was trying to say last week and in my explanatory email, nothing can be mandatory, even if we say 'SHOULD' it doesn't contribute to binary conformance, but it still carries some weight because it gives designers intent.
Kris; your mail was helpful, I don't think folks understood your last week's spoken words as well as your email, so thanks for sending it.
Don; I just focused on an example, the q' element; by my analysis, one of those did not make sense with a SHOULD.
Kris; but for the 'q' element, we don't have authoring statements as normative, only processing statements.
Kris; any others have comments about the 'q' element?
Robert; the 'q' element doesn't have a lot of good implementations, so I'm wary of directives to authors on that element.
Eliot; 'q' is particularly problematical, not such a good case for us to focus on in this sense.
Robert; 'q' is an exception to the norm on this.
Kris; Then let's shelve discussion on 'q' for this subject. Rather, should we have rendering guidelines in the spec, or move them to an adjunct document?
Eliot; I like the idea of an adjunct document, but not to remove the awareness of guidelines from the spec.
Robert; I like that too, since it will make the spec smaller, with pointers from the spec.
Kris; but we will still have some normative language on rendering in the spec, though not as much, e.g. draft-comment and required-cleanup
Nancy; should there be pointers from the spec to the adjunct document?
Don; don't think the 1.3 spec can be changed.
Nancy; this is for the future, not 1.3
Robert; right, this is for 2.0. Someone could come up with the adjunct doc for 1.3, but it won't change the actual spec.
Kris; and for 2.0, what about nancy's suggestion? From a design point, how much do we want to remove from the spec? Some of it is more necessary that other; e.g. if we remove stuff from 'sl', people won't understand what a simple list is intended to be.
Eliot; for each relevant element, could have an optional section called 'rendering expectations', which would be non-normative, that gives rendering guidelines.
Kris; yeah, if it's a standard section, it makes it easier to pull out for an adjunct document.
Eliot; I was thinking in the other direction, actually.
Robert; should it be included as part of metadata for langref topics?
[to be continued, in the meantime, go to item #7]
7. New item: 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
Robert gave overview; the first conformance clause was in the 1.2 spec, as required by OASIS. It asked processors to list what they didn't support, but never declared in the spec what was/was not a feature. At 1.3, we got pretty harsh feedback from TAB on conformance clause; they felt it was impossible to comply with. If you don't know what DITA is, it's impossible to understand the conformance statement. We need to start with the clause at 2.0; we need to start out with a list of features, and with links to them. Features will then come with their own rules. Also, we need to defines types of processors, with the features each needs to support. This will need much more focus in 2.0.
Kris; that's a good review of our discussions. We couldn't bring it up for 1.3, but we need to bring it up now because it really impacts the next release.
Robert; in our discussion, Chet realized that we could make it more 'conforming' by making it simplistic and completely useless, so he agreed that we should keep it as it was.
Kris; what about DocBook?
Dick; I can look into it and report next week.
12:00 PM ET Close
-- Ms. Nancy Harrison
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]