dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 26 March 2013 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Sun, 31 Mar 2013 21:50:00 -0700 (PDT)
Submitter's message
Here are the mi nutes for last week's TC meeting:
Minutes of the OASIS DITA TC
Tuesday, 26 March 2013
Recorded by N. Harrison
regrets: Tom Magliery, Deb Bissantz
Standing Business
=================
Minutes from last meetings:
https://lists.oasis-open.org/archives/dita/201303/msg00076.html (19 March, Harrison)
Proposed by Kris, seconded by MichaelB, approved by TC
Subcommittee Reports:
Machine Industry SC; Chris Kravogel (SC chair)
Action item; Don to contact chris Kravogel wrt his reporting on the status of the Machine Industry SC
Announcements:
None
Business
========
1. DITA 1.3 progress
Progress between March 18-24, 2013: https://lists.oasis-open.org/archives/dita/201303/msg00070.html
Update on deadlines: https://lists.oasis-open.org/archives/dita/201303/msg00071.html
Trello Board:
URL for Trello Board: https://trello.com/b/gPKH0OcF
As of 25 Mar 2013, the following voting member still needs to join: Seth Park
Kris went over the status of proposals wrt deadlines with proposal owners, she and/or owners will update Trello as appropriate.
2. DITA 1.3 proposals, stage 2: http://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage2
Ready for discussion on 2 April:
13090 - DITAVAL style enhancements (Nitchie)
https://lists.oasis-open.org/archives/dita/201303/msg00077.html (HTML)
https://lists.oasis-open.org/archives/dita/201303/msg00078.html (DITA)
Ready for vote: Voting options are "Yes," "No," "No objections," "I don't understand the proposal," and "I have reservations"
None
3. DITA 1.3 proposals, stage 3: https://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage3
Ready to assign reviewers
None
Discussion
None
Ready for vote: Voting options are "Yes," "No," and "Abstain"
None
4. New ITEM: Which attribute binding is effective?
https://lists.oasis-open.org/archives/dita/201303/msg00049.html (Eberlein, 18 March)
Kris gave an overview; the question is how the attribute binding works if, within a complex document, the same attribute is bound to different keys. This is mostly used for pick lista, and it affects how DITAVALs are implemented. We don't have any wording in spec if someone tries to bind different subjects to the same attribute/key. We need to provide some guidance. currently, e.g., Oxygen does it differently from DITA-OT.
Eliot; what would users think is reasonable? I think it would be the union of the key definitions.
Robert; what if for my product, one scheme is a subset of the other?
Eliot; The only real solution is to have the values mergerd, and to have 'first one wins' which is what happens in most cases.
Kris; if a company has a huge taxonomy of what are all the diff possible OS's, a group within it only wants to deal with the subset, and wants to only work with that subset. I'm telling peole to separate enumeration from taxonomy in order to get what you want,
Eliot; It doesn't take much to get into schema definition between restriction and extension. if I want to narrow something down, I can create a new map with the limited set.
Kris; In the spec, we just don't talk about enumeration and how it's bound, and we need to.
Robert; Extension is already possible by 'redefining' a scheme
Kris; Having raised this, I'm happy to go on with it; I can throw up wiki page with some thoughts, and anyone can comment on it.
Action Item for Kris; set up wiki page on this topic.
Action Item for TC; if anyone has thoughts,, send them to Kris.
5. NEW ITEM: Looking for input on table summary proposal 13085
https://lists.oasis-open.org/archives/dita/201303/msg00080.html (Anderson, 26 March)
Robert went over his proposal 13085, which he'd sent out mail about earlier; it looks like the new HTML5
Adrian; The HTML5 guidance on this is that 'the experience for reader should be the same whether or not they are impaired' so Robert's proposal aligns with this.
Don: There's no exact equivalent between the 2 constructs, so we can't equate to accessibility features.
Robert; I don't think I'm suggesting that; I just want to make tables accessible.
Nancy; Do we need to add doc to 1.3 to clarify this?
Robert; We generally try not to give that kind of info in the spec.
Don: TC is in a good position to recommend this, in a non-normative way.
MikeB; We should at least have the info somewhere, to give guidance.
Robert; the current spec already says that desc is where you're supposed to put this kind of info. We definitely don't want to asy 'this element is for screen reader ddescriptions', because it will make people hide it. I'm on the fence as to whether it's needed, and in the name of not increasing complexity, we should at least put this on hold.
Kris; Robert, at this point do you want to withdraw this proposal?
Robert; I think so, the only question is whether any language is needed in the spec. if someone will suggest language, that would be great.
Kris; Unless someone steps forward to own the doc changes, let's withdraw this
eliot; If we're talking about accessibility, we need to do accessible table row headers.
Robert; In DITA-OT, when you use a table, thead and rowheader exist; we don't let you specify any other column besides the 1st as a header.