dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 19 March 2013 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 25 Mar 2013 16:57:18 -0700 (PDT)
Submitter's message
Minutes of the OASIS DITA TC
Tuesday, 19 March 2013
Recorded by N. Harrison
regrets: Thilo Buchholz, Joann Hackos
Standing Business
=================
Minutes from last meetings:
https://lists.oasis-open.org/archives/dita/201303/msg00056.html (12 March, Day)
Proposed by Don, seconded by DickH, 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 11-17, 2013: https://lists.oasis-open.org/archives/dita/201303/msg00054.html
Update on deadlines: https://lists.oasis-open.org/archives/dita/201303/msg00055.html
Trello Board:
URL for Trello Board: https://trello.com/b/gPKH0OcF
2. DITA 1.3 proposals, stage 2: http://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage2
Ready for continuing discussion:
None
Ready for vote:
None
3. DITA 1.3 proposals, stage 3: https://wiki.oasis-open.org/dita/DITA_1.3_Proposals-stage3
Ready to assign reviewers: none
Ready for discussion: none
Ready for vote: none
Voting options are "Yes," "No," and "Abstain"
Queued up for review by assigned reviewers; awaiting complete proposal:
13089: learningObjectMap & learningGroupMap (--> L&T SC; due on 18 April)
Three proposals from TechComm SC (13096, 13086, 13098)
https://lists.oasis-open.org/archives/dita/201303/msg00007.html (single zip file, Park)
Assigned reviewers: Stan Doherty, Eliot Kimber, Thilo Bucholtz, Kris Eberlein
Seth Park reported that the TechComm SC will have the troubleshooting proposals ready for stage 3 review very soon, hopefully they should be ready to vote on soon after they go for review
Robert brought up the issue he raised re: #13079 via email (https://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201303/msg00050.html) on Mar 18th. This proposal is really about fixing the keyref matching text in the spec, so it's really a doc item. The TC agreed with this suggestion, so Robert will move it to the list of doc items for 1.3.
Don tried to reach John Hunt and Mark ?? (previous co-chair of DITA for the Web SC) re; delivering a DITA mime type as part of DITA 1.3. At this time, Mark can't work on it. So the question is; is this important enough for us to pursue, and if so, is there anyone interested in working on it? Is there anyone who would make use of it?
Eliot noted that a lack of it doesn't seem to have been a barrier, so maybe the answer to the above questions is 'no'
Don; The issue is that it will take a substantial bit of work, and require input and acceptance by a number of people, so it needs to be part of a real effort, if it's going to happen at all.
Action Item: Don to contact John Hunt wrt his availability in working on creating a DITA mime type, either within the DITA for the Web SC or not.
4. Discussion before (or in lieu of) a formal stage-2 proposal:
Proposal #13121: Reusing portions of structural specializations via domain mechanism
https://lists.oasis-open.org/archives/dita/201303/msg00036.html
MichaelP recently sent out the about mail, and it includes 5 doc items associated with the proposal:
Items 1 & 2 have been captured on Trello, and RobertA has added 4 & 5 as well.
Today, we need to finish discussion of the line items:
MichaelP was concerned that we needed more flexibility, but now he's not so sure; he's still considering the issue
re: Michael's doc item:
generalization section - need to update section that claims doctype can be auto-generated - no longer really true, may not have been for some time
- also need to think through impact of the advice to include structural classes in the domains list - what will that do to conref and generalization rules?
- also if structural classes are recommended to be included in the domains list, the examples given - and our own domains used in DITA - should be updated
MichaelP had originally claimed that a doctype can be auto-generated from a list of domains/class attributes; he's not sure if that's still true, so he'll either remove that section from the proposal, or update it with specifics. For Lightweight DITA, he'd like [topic] nesting to have a better name.
RobertA: This language was added with 1.2, in the specification we strongly suggested that specializations add in their own domain module. In particular, Eliot wanted that language, because domains are global. But in a sructural specialization, maybe you couldn't do that?
MichaelP; if you had constraints that were more general, it would be tough to get that info. Or if you had a domain integration that wasn't 'total' e.g. you want to integrate 3 out of 5 elements in the highlighting domain.
Eliot; You can integrate the highlight domain elements, and still leave out of standard use. But you then need a constraint on that.
Robert; there's a naming convention that says its a constraint. As long as you have a naming convention between your constraints and the module, you can automatically assemble document type that will validate.
MichaelP; e.g. if I get rid of element, is there a specific way to do that? That is, in that situation there is no actual file that you're pulling in, where something is a 'virtual' constraint, that becomes something we don't currently hae language to make it possible. I think that we can create a document that would validate against the original, though it may not have all the constraints of the original.
Robert; Do you want the language refined to reflect the above statement?
Eliot; I have a proposal in to have that, but it's pretty low priority, since nobody cares about it.
Robert; so this comes down to another specification item; that statement is not true today and needs to be fixed.
Action Items:
- Michael P. will create a DITA 1.3 documentation proposal for the 3rd doc item ('constraints section') on his mail https://lists.oasis-open.org/archives/dita/201303/msg00036.html
- Michael will deliver Stage 2 proposal for DITA structural specializations by the end of March (item will not be on agenda for next meeting).
5. New ITEM: Which attribute binding is effective?
https://lists.oasis-open.org/archives/dita/201303/msg00049.html (Eberlein)
Robert gave some background; you can have nultiple subject schemes, in each of which a different definition of same key is valid . If there are 2 different declarations, which declaration takes effect? are they merged? The spec needs to clarify that, but RobertA isn't certain what the answer actually is.
Eliot noted that he'd thought about it briefly, but hadn't come up with a definitive solution
RobertA; The TC will just have to pick something
Don; In order to do that well, we need use cases
RobertA; The issue is that there hasn't been so much use of the feature.
Resolution; leave discussion to next week, when Kris will be on the call, since she's the one who brought it up.
6. New ITEM: Cross-Deliverable Linking
https://lists.oasis-open.org/archives/dita/201303/msg00048.html (Kimber)
https://lists.oasis-open.org/archives/dita/201303/msg00051.html (follow on)
Eliot gave an overview; he's giving a talk at DITA/NA and he's working on testing what he and MichaelP are working on. In the process, he realized that (2nd message), as the author of the map that links to a peer map, you have to know what maps are the roots of your peer map. There's nothing in a map which indicates whether a map is a root map or not. We need to understand that because it affects our potential solutions
There are 2 possible ways to handle this:
1. define a new syntax that lets you reference a root map as a keyspace
2. include all the peer maps in your referencing map, with scope = peer, to show those are peers not part of the referencing root map, but that requires a global keyspace across everything, but if so, you need to know which other maps are root maps
RobertA; in the DITA 1.2 timeframe, we talked about what it means to reference a map with scope=local or peer; i.e. does that mean the map itself is local, or does it mean that a map itself is a peer or external map. That decision resulted in changes to IBM's handling of maps.
Discussion of this topic to be continued next week.
closed at 12 noon
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]