OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

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



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"

3. DITA 1.3 proposals, stage 3: https://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage3
Ready to assign reviewers
Ready for vote: Voting options are "Yes," "No," and "Abstain"

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
can be used much more like our element. So he tinks this proposal should be scrapped, and we should just use to align with 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.
and @rowheader have been enough for anything in IBM except wanting a rowheader for a middle column.
Eliot; This came up for us at RSI working with the Federal Reserve, but they only needed it on the first column,
Robert; Also, with simpletable, you can specify which column is the most important column.
DickH; docbook is working on the same thing; if something happens there, I'll will report on it.
Resolution; Proposal 13085 will be withdrawn

6. New ITEM: Cross-Deliverable Linking: Requires a-priori knowledge of which maps are root maps
https://lists.oasis-open.org/archives/dita/201303/msg00051.html (Kimber, 18 March)
https://lists.oasis-open.org/archives/dita/201303/msg00061.html (Nitchie, 20 March)
https://lists.oasis-open.org/archives/dita/201303/msg00062.html (Anderson, 20 March)
https://lists.oasis-open.org/archives/dita/201303/msg00066.html (Kimber, 23 March)
https://lists.oasis-open.org/archives/dita/201303/msg00067.html (Kimber, 23 March)
https://lists.oasis-open.org/archives/dita/201303/msg00068.html (Kimber, 24 March)
https://lists.oasis-open.org/archives/dita/201303/msg00069.html (Nitchie, 24 March)
Eliot; we need to be able to link across document sets.
Chris; You've previously said you need the same thing for scope keys to address keys in a particular scope
Eliot; Topics bound to a key need that key in their address space (in their root map) in order to use the keys. I've given a proposed syntax for resolving keys outside the local key space.
Kris; This is linked to some of your proposals; is this something you want feedback on?
Eliot; i want to get validation that my analysis is correct from the persons most concerned, especially MichaelP, Robert and ChrisN. if we talk about key scope, one question is 'if you address key in key scope, you have to put a name on the scope itself; is that name hierarchical?' That is, if scope 'a' contains scope 'b' contains scope 'c', do I need to mention the complete hierarchy, or can I have a single name that incorporates all of them? For any key that you want available globally, you need a global name for it; it needs to be defined in your root map.
ChrisN; This goes back to a change that I'm going to make with the scoped keys proposal: a keydef or conkeydef that applies for a given keyref with scope is the one made in the most global space. We want to define scope in 'scope_1' so that from outside scope, you could reach key foo in 'scope_1' by using the syntax 'scope_1.foo'; this puts the onus on authors to define scope correctly.
Eliot; I'm not sure what you mean by personal key def
ChrisN; In my previous example, 'scope_1.foo', that is then available in all *refs that are in the parent of scope_1
Eliot; I would expect that a *ref to an unqualified key is to a key in the local scope.
ChrisN; I'm saying you can put the onus on the map developer to define keys correctly.
After a long discussion between Eliot and ChrisN, Don suggested that we need some use cases for this, e.g., from someone who has constructed a map dynamically; they might not have any way of knowing what's there.
Eliot; The agent that created the map, dynamically or not, needs to have knowledge of the key spaces; dynamic generation doesn't change the problem. The question is, who has knowledge at what time? No processor can ever have complete knowledge of all the context where the key might be used.
ChrisN; We still has the notion of qualified key refs, but we'd like to have simple key names.
Kris; Do we need to carry this over to next week?
Eliot; ChrisN and I may be saying thw same thing...

Resolution; TC will take this item off next week's agenda, but it might return later.

closed at 12 noon

-- Nancy Harrison
Document Name: DITA TC Meeting Minutes 26 March 2013

No description provided.
Download Latest Revision
Public Download Link

Submitter: Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2013-03-31 21:49:52

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]