dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 27 Januarty 2015 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Tue, 27 Jan 2015 09:40:36 -0800 (PST)
Submitter's message
ActionItems:
1. Robert will remove 'term' from text and fix examples wrt
1.2 / 1.3 key processing topic for link text.
2. All TC members should look at new constraint rules and send comments TODAY (otherwise Kris will take them as correct and agreed on).
3. Kris will fix the definitions of strong/weak constraints.
4. all TC members should read rest of "Coding requirements for constraint modules" topic and post any concerns to the list.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 27 January 2015
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets:
Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201501/msg00118.html (20 January, Nancy Harrison)
Proposed by Kris, seconded by Dick, approved by TC
Subcommittee Reports
none
Announcements
Business
========
1. Action items
- Action items from 6 January 2015:
Robert: Remove mentions of XML Data type from LangRef topics
Robert; this is now complete
- Action items from 13 January 2015
Nancy: Schedule meeting with Jean-Jacques Thomasson
Nancy; I now have the info I need to get started on this; will start today)
2. Report back on meeting about dita.xml.org
https://lists.oasis-open.org/archives/dita/201501/msg00124.html (Day, 27 January 2015)
Don: we had good participation, looking forward to having Michael join in future meetings. We met with a goal of working out next steps. To choose a primary vendor, we'll need a selection process. We will have Q&A sessions with both prospective vendors and interested TC members from both TCs. We came up with some new considerations (e.g. hosting cost, converting legacy content). If anyone wants to be involved, they need to be involved and committed to work through the whole process. I'll be open to anyone's questions about the process.
Kris; we're looking for more TC participation, expecially from members who aren't regular participators in weekly calls. The work can be grouped in 2 phases; 1, initial evaluation, 2. an effort towards assesssing what's currently on the site, with a view to conversion and archival of legacy info.
3. Targeted reviews progress: January - February 2015
- Link to DITAweb: https://ditaweb.com/oasis-dita|DITAweb
- Processing etc.: All voting members are asked to participate
Jan 06-12: Conref - CLOSED; editorial work completed; review archived
Jan 20-26: Conditional processing (6 pages)--CLOSED
Jan 27 - Feb 2: Subject scheme (13 pages)
Kris; especially in relation to subjectscheme, we want to make sure that comments are rooted in 1.3, not 1.2.
TBD: Direct addressing; DITA linking; Keys; Branch filtering; Keys revisited
- Configuration, specialization, and constraints:
Jan 06-12: Constraints (19 pages)
Jan 13-19: Constraints (19 pages) -- CLOSED; editorial work on-going; review archived
Kris; there's some rewrite work remaining, relating to later items on agenda
Robert; I did a pass last week to incorporate comments, but more added since then.
4. New item: Error in 1.2 / 1.3 key processing topic for link text
https://lists.oasis-open.org/archives/dita/201501/msg00074.html (Anderson, 20 January 2015)
https://lists.oasis-open.org/archives/dita/201501/msg00075.html (Anderson, 20 January 2015)
Robert: this came out of Jarno's comments; in 1.2, when we defined key replacement text, we said 'content would come from content or 'keyword' or 'term', but 'term' isn't legal in that context. There are a few possible actions we could take, but we think the best is to remove 'term' from that language.
Eliot; I agree
Kris; any comments? Any objections?
[none of either]
ActionItem; Robert will remove 'term' from text and fix examples.
5. New item: Problems with the "figure" under 'val' element in the Language Specification
https://lists.oasis-open.org/archives/dita/201501/msg00102.html (Thomas, 24 January 2015)
https://lists.oasis-open.org/archives/dita/201501/msg00106.html (Anderson, 26 January 2015)
Robert; I sent response, and Bob agreed
Kris; does that mean we need some work on wording on groups?
Robert; yes, and other comments to conditional processing material suggest same thing.
Resolution; none needed
6. Targeted review comments: Constraints
- New item: Post-targeted review test of "Constraint rules"
https://lists.oasis-open.org/archives/dita/201501/msg00097.html (Eberlein, 24 January 2015)
Kris; I sent out new rules, got some comments back
ActionItem; All TC members should look at new constraint rules and send comments TODAY (otherwise Kris will take them as correct and agreed on)
- New item: Normative statements about strong and weak constraints
https://lists.oasis-open.org/archives/dita/201501/msg00105.html (Eberlein, 26 January 2015)
Tom; one suggestion; pretty clear that processors check and enforce validity; why not say that explicitly?
Kris; if we're making a SHOULD, rather than a MUST statement, that's problematical. We're not sure all processors do that. If they support it, they do that. Any thoughts, Michael?
Michael; do we want to say what that 'validity' means?
Kris; a later topic gives pretty clear examples.
Michael; if we have some rally good examplles of what strong/weak contraints imply, that should work.
Kris; I'm thinking of incorporating that content into this (strong/weak constraints) topic. We have a lot of work to do on constraint; given all the comments we got in the first review; but I wanted some comments on these reworked pieces.
Dick; there does need to be a real definition of these things (strong/weak constraints); the definition in the topic seems circular ('if it's weak, it's not strong')
ActionItem; Kris will fix the definitions of strong/weak constraints
- New item: Updated "DTD: Coding requirements for constraint modules" topic
https://lists.oasis-open.org/archives/dita/201501/msg00119.html (Eberlein, 27 January 2015)
https://lists.oasis-open.org/archives/dita/201501/msg00122.html (Kimber, 27 January 2015)
https://lists.oasis-open.org/archives/dita/201501/msg00127.html (Eberlein, 27 January 2015)
long discussion on whether file-naming convention should be normative (SHOULD) or not.
Eliot considered it important for the information to be together with the coding conventions so it wouldn't get lost, and for file-naming to be part of coding rules, to help out implementors who inherit other peoples systems, but others convinced him that
1. file naming practices are just that - best practices - and not part of normative content (Robert and Chris noted that the 'rules' currently in the spec are rarely followed, and with no adverse consequences to the 'rule-breakers')
2. if we move all file-naming information to an appendix, and link to that appendix from all the places where it's relevant, it will be just as useful, and just as likely to be read, as if we leave the info scattered around in the various processing topics/examples
Bob noted that this would be a very important appendix, and suggested that it be mentioned in the intro to the spec.
Nancy was concerned with the effort involved in going back to previously completed topics and pulling out file-naming, but Kris and Robert noted that the file-naming material is pretty much all in the not-yet-rewritten secions, so 'it should be a wash'.
ActionItem; all TC members, read rest of "Coding requirements for constraint modules" topic and post any concerns to the list.
7. Review #2 comments:
- Continued item: Branch filtering: ditavalref as child of map
Eliot; just fyi, I'm now in agreement with Robert on ditavalrefs as child of map.
[will review conclusions next week]
meeting closed at 11:59
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]