dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 9 December 2014 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 5 Jan 2015 15:28:23 -0800 (PST)
Submitter's message
Action Item:
ChrisN will submit language for Cross-deliverable links and key resolution, and on the TC resolution on unresolvable key maps. (this is already complete as of Dec 10; links to discussion thread items are included at end of minutes.)
=================================================
Minutes of the OASIS DITA TC
Tuesday, 9 December 2014
Recorded by Nancy Harrison
link to agenda for this meeting:
https://wiki.oasis-open.org/dita/PreviousAgendas
Regrets: Stan Doherty, Dick Hamilton
Standing Business
=================
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201412/msg00002.html (2 December, Nancy Harrison)
http://www.boston.com/news?p1=Levelone_Nav_news_hpProposed by Kris, seconded by Don, approved by TC
Subcommittee Reports
scheduled: Lightweight DITA SC
[In Michael's absence, moved to Dec 16 or January]
Announcements
Don will chair Dec 9 meeting; Kris may not be available.
Business
========
1. Action items
Action items from 4 November 2014:
L & T subcommittee: Make changes as needed to the L & T section of the archSpec. Due by 16 December 2014.
Action items from 2 December 2014:
Kris: E-mail to Jean-Jacques Thomasson. (Completed)
Kris: E-mail about French-speaking translator to help with meeting with Jean-Jacques Thomasson. (Completed)
Kris: Set up meeting to follow-up on dita.xml.org RFPs. (In progress) talk to Keith after call
Eliot: Move RNG-to-DTD-XSD generator code to GitHub - no progress, since he still has a bug fix to do before he can move things
Chris: Read review #2 comments about normative language and key scopes; respond to list. (Completed) robt, kris, chris, eliot, jarno, ? will look at language.
Bob: Review TC minutes and dita-comment e-mail for discussions of strong & weak constraints. - looked at minutes and email notes; sent out a summary message (completed)
2. Update about dita.xml.org site RFP (Eberlein)
Mekon (DITAweb), Suite Solutions (SuiteShare), and Oberon Technologies (HARP) expressed interest in providing technology and hosting the site.
Ixiasoft has expressed interest in providing a CCMS, if that is needed.
Meeting of TC members being planned for later this week.
Kris; heard from Mekon, SuiteSolutions, Oberon Technologies; small group will meet later this week.
3. 2nd spec review progress: 13 October - 1 November 2014
REVIEW CLOSED 1 November 2014
https://wiki.oasis-open.org/dita/1.3-spec-review-#preview
Update from Kris and Robert
Robert; last week and yesterday, I spent 5.5 hrs on phone, added dispositions on spec; have now dispositioned every part of spec except 'Configuration, specialization, and constraints' section. Kris added dispositions to spec over weekend. Kris also sent out note on how we will proceed.
5.50 hours spent in conference call assigning dispositions of comments (Anderson & Eberlein, each)
14.0 hours spending handling dispositioned comments (Eberlein)
X hours spending handling dispositioned comments (Anderson)
The following sections of the spec review have not yet been discussed:
Configuration, specialization, and constraints
Appendixes
4. Clarification about spec process
https://lists.oasis-open.org/archives/dita/201412/msg00034.html (Eberlein, 8 December 2014)
Robert; above email is a short idea of how we will proceed. describes how we've gone thru things. Once we've done, will have a short review on the sections we're doing the most work on, which got the least review in the beginning. We'll need a lot more reviewers for that stuff; we will send out short targeted reviews on this material, and try to get everyone to review them
Kris; we won't wait to start those reviews until we've finished completing spec; we'll send out material as soon as we finish a section. Expect to see them staring later this week. Any preferences on what tool to use? PDF review? DITAWeb?
Nancy; I'd prefer DITAWeb
Robert; note on above mail item #3; please don't comment on stuff except during the short review. on item #4, our hope is to have a small group with all previous commenters (see above list of 5 members listed in item #4) together to work out language.
Will have to work hard to get spec out in March; working in small chunks will hopefully make it a bit more doable
Kris; we will be counting on increased participation from TC members during small reviews;
Keith; can you ballpark a weekly hourly figure?
Robert; depends on how closely you want to review each section. some are very technical; some folks have not wanted to review them for that reason. we hope that the language in the 1.3 spec is now understandable to anyone with a basic knowledge of DITA; if the language isn't understanable, that's exactly what we want to know.
Kris; if there's content you don't understand, it would be important to have that info from each TC member. The spec could go out with some items of primary interest to implementors not understood by 100% of TC, but most of it needs to be understandable, and understood, by all of the TC.
Robert; right, we should all have a decent handle on most of the spec. for each section, maybe an hour or two at least to review, except for keys, which will be more.
Kris; remember, if you have a less technical person, and you have someone in company who knows more. have them each review the parts of the spec that are the most relevant to them.
Stan; is there currently support in toolkit for these new features?
Robert; for most new features, there's not yet support in the OT. For basics, we should have support there, but just because the toolkit does something, that also doesn't mean it's a canonical implementation.
Kris; that will apply to any DITA implementation. and for these edge case areas, you won't have any luck trying to validate it with a current processor
Kris; direct URI-based addressing review; will try to get that this week, and get a tentative schedule for rest of topics.
5. Review #2 comments:
- Continued item: Links between maps
https://lists.oasis-open.org/archives/dita/201411/msg00036.html (Eberlein, 4 November 2014)
https://lists.oasis-open.org/archives/dita/201411/msg00037.html (Kimber, 4 November 2014)
- Continued item: Keys in peer root maps
https://lists.oasis-open.org/archives/dita/201412/msg00004.html (Eberlein, 2 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00009.html (Kimber, 4 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00012.html (Nitchie, 4 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00014.html (Kimber, 4 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00026.html (Nitchie, 8 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00035.html (Helfinstine, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00036.html (Kimber, 9 December 2014)
Eliot; first 2 items above are now mingled; discussion is ongoing, under various subject lines, comes down to
1. what is the effective precedence of peer maps, with respect to what's defined in a local map?
If a peer map comes first
1. are any of the keys in a local map qualified with same scope as peer map? if so, are those overwritten by peer map?
2. ref to key in peer scope, is key resolvable yes or no, to answer, we need peer map available, or a rule that says, it's resolvable even though I don't know.
Kris; Chris, can you respond?
Chris; I'm surprised we're talking about special cases; I don't want to tie map authors' hands by a blanket rule, and I think the current key precedence rules cover them. If a peer map is unavailable, and it might be resolvable when the peer map is available, what should the processor do?
Kris; any other comments. and in discussing this, are we broadening the scope of the original 1.3 proposal?
Eliot; not broadening, just want to get clear what the rules should be.
Robert; ditto, Eliot
Eliot; Davidh, what about when you have a peer map, and it has a ref to another peer map? if so, the only way to know what to do is to process all the ref'd peer maps. One very specific case; a peer map is ref'd in map tree before another submap, and that submap ref's same peer map; this is separate from the issue where we have reference to a key
Chris; a reference to a key that 'might' be defined; a key whose scope qualification is the same as the peer map, and no local key qualiifcation.
Chris; and you can't know answer to that question
Eliot; right, one way to solve the problem is to say 'even if peer map is available, and your map can go get it, it's still a possibiity you have to resolve other peer maps if they're refenced from that peer map. in cross-deliv. linking, you nevver know if a key is resolvable until you do it.
Chris; but any document that relies on multiple maps has that problem; things can change from day to day.
Eliot; but without cross-deliv. linking, you know that when you process it. With cross-deliv. linking, you can't have that. so what is the rule that gives us the most appropriate result, that requires least superfluous processing, and gives the least surprises for authors. In the case where a peer map isn't available, what does it require or allow for processing?
Chris; I think it should be normative 'should'. in a validation scenario, I would want a warning. any unresolvable key should or must result in a warning.
Keith; and if there's fallback, we rely on fallback.
Chris;??
Eliot; if I have a ref to a key in a peer map, that has higher precedence, but if we have a local key, we get local key
Chris; so if there's a local key, that's what we use by default.
Eliot; but in that case, we have a local scope qualified map that matched peer map, wouldn't author want to be informed?
Chris; not if I've deliberately put a fallback into a local map in case the peer map isn't available.
Eliot; so the implication is that, if peer map is unavailable, treat it as what?
Chris; so we'd give a warning, not an error, in that case; when an unresolvable key ref might be in a peer map, issue a warning, not an error.
Kris; I want us to firgure out a way to come to resolution on this issue this week, so we can move forward and address all our other comments.
Eliot; think we're closing in on 2 main cases:
1. a ref to key in peer scope and no local
2. a ref to key in peer scope and a lower precedence key in local;
Chris; So for #1, it's an error, with extra info. For #2, no warning needed.
Kris; Chris; please repeat your statemeent in an email.
AI chris will send repeating his phrasing of resolution of this issue.
Followup mail exchange:
https://lists.oasis-open.org/archives/dita/201412/msg00037.html (Nitchie, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00038.html (Nitchie, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00039.html (Kimber, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00040.html (Kimber, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00041.html (Anderson, 9 December 2014)
https://lists.oasis-open.org/archives/dita/201412/msg00043.html (Nitchie, 10 December 2014)
Request:
Kris; we need a volunteer in tracking these items in Trello?
Tom M. volunteered.
meeting closed at 11:59
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]