dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 10 Dec 2013 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: dita@lists.oasis-open.org
- Date: Mon, 16 Dec 2013 22:45:15 -0800 (PST)
Submitter's message
Action Items:
Kris to set up conference call to discuss 13060 & 13061
==================================================
Minutes of the OASIS DITA TC
Tuesday, 10 December 2013
Recorded by N. Harrison
regrets: Mark Myers,
Standing Business
=================
https://www.oasis-open.org/committees/download.php/51668/minutes20131203.txt (3 December, Nancy Harrison)
Proposed by Kris, seconded by Don, approved by TC
Subcommittee Reports
none
Announcements:
none
Business
========
1. DITA 1.3 progress
Progress: 2 - 9 December 2013: https://lists.oasis-open.org/archives/dita/201312/msg00054.html (Eberlein, 10 December 2013)
Trello Board: https://trello.com/b/gPKH0OcF
Kris gave an overview on current status from the above links
2. DITA 1.3 proposals, stage 3
Ready for vote: Voting options are "Yes," "No," and "Abstain"
Proposal 62: Table accessibility (Reviewers: Eliot Kimber, Don Day, Stan Doherty)
Proposed by Scott, 2nded by Dick, approved unanimously by TC
Yes votes: Anderson, Bissantz, Day, Doherty, Eberlein, Hackos, Hamilton, Harrison, Helfinstine, Hudson, Kimber, Magliery, Nitchie,
Proposal 13060: Enhancement to 'resourceid' (Help SC; Reviewers: Scott Hudson, Deb Bissantz, Robert Anderson)
Based on comments from Eliot & Nancy, moved this back to discussion along w/13061
Proposal 13056: Expand syntax for filtering attributes (Anderson; Reviewers: Deb Bissantz, David Helfinstine)
Proposed by Robert, 2nded by David, unanimously approved by TC
Yes votes: Anderson, Bissantz, Day, Doherty, Eberlein, Hackos, Hamilton, Harrison, Helfinstine, Hudson, Kimber, Magliery, Nitchie, Priestley
In review:
none
Ready for discussion:
13061: UA window definition (Help SC; Reviewers: Don Day, Robert Anderson)
https://lists.oasis-open.org/archives/dita/201312/msg00032.html (DITA, uploaded 26 November 2013; updated 4 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00031.html (HTML, uploaded 26 November 2013; updated 4 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00055.html (Kimber's comments, 9 Dec; forwarded to list 10 December 2013)
Tony gave the overview; goal is to allow window definition & behavior to be stored in a map through new @s to resourceid.
Eliot's main conern was that there's no wrapper element within the map to contain the ux-window element (2 for 13060). What are the precedence rules if there are 2 ux-windowref elements with the same name value?
Tony; there could be a precedence issue; Eliot's mail spells out some ideas on that; we can spell that out in the spec doc. As for the location in a map, it's under the root; we haven't had any discussion of moving it. For use cases in online help, the question of multiple windows didn't arise.
Eliot; my concern is wrt gen'l markup design in a map; the way it's been implemented means that we don't e.g. have the ability to do a conref, because it's not part of the navigation.
Kris; so do you not want it to be a direct child of map?
Eliot; I'd prefer it to be available in topicmeta, or topicref
Tony; would it be only in topicmeta in map, or also under topicmeta under topicref? The design isn't meant to let a ux window definition be a child of a specific topicref, so while it would be OK if it could be in topicmeta in map, it would be confusing to be within topicmeta under topicref. In the online help use case, even in a collection of topics, there would only be 1 or 2 or 3 elements within a map. How would that change how they'd be managed?
Eliot; as long as there's more than one, e.g. in one branch I want one window geometry, for another branch i want a different geometry, so it should be able to be scoped to a branch of the tree.
Robert; theoretically, you could also conref just a branch of a map, not the whole map. So I think it should be only available one way, so only under topicref.
It became clear at this point that the discussion was going to take a long enough time that it wasn't appropriate to have it during a TC meeting, so Kris offered to set up a conference call to have a fuller discussion; participants to be Kris, Tony, Stan, and Robert (Eliot is traveling, but felt robert could represent his POV in the discussion).
ActionItem: Kris to set up conference call on this issue.
13060; shall we just bring up this in the extra call?
Tony;
eliot; The point here is that it's possible to have 2 ux-windowrefs in a map, if so, which one counts?
Tony; I'd say the last one; mandating how the processing goes; you could end up with multiple windows in system; but we could state a top-down prcedence
Kris; that would be parallel to what we do with keys.
Eliot; it's dangerous to define it in terms of how processor works. Currently our standard precedence is 'first one wins'
Kris suggested, and it was agreed, to move thuis discussion to the same call where 13061 will be discussed
13059a: Ability to filter within a branch of content (Anderson; Reviewers: Kris Eberlein, Eliot Kimber)
Submitted to reviewers on 1 November
https://lists.oasis-open.org/archives/dita/201312/msg00036.html (PDF, uploaded 6 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00035.html (HTML, uploaded 6 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00034.html (DITA, uploaded 6 December 2013)
[NB: a small group call took place on this topic over the last week.]
Robert gave an overview on recent changes to this proposal; basically this proposal provides a way to specify a condition to a subset of content; the question was on processing order; processors have to understand the full document space, and have to understand how branch filtering is going to work. Branch filtering will determine how processing needs to go; there's a new section in the proposal on the implications of filtering order, and examples were updated to make things clearer.
Resolution; this proposal will be voted on next week
13106: New base domain and specializations for question/answer interactions (Kimber for L & T SC; Reviewers: Hackos, Dawn Stevens)
https://lists.oasis-open.org/archives/dita/201312/msg00037.html (PDF, uploaded 16 November; updated 6 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00038.html (DITA, uploaded 6 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00039.html (HTML, uploaded 6 December 2013)
Eliot gave the overview; this is an attempt to fix a flaw in the original DITA L&T design by allowing 'div' in any place you can have text, so he had to go back and define a branch that replicated the domain, learning2. The new one gives much more flexibility. A change was made based on stage 3 review; the addition of examples giving all the new functionality, to make it clear what's allowed.
Resolution; this proposal will be voted on next week
13112: RelaxNG for DITA vocabulary (Kimber; Reviewers: Scott Hudson, Dick Hamilton)
https://lists.oasis-open.org/archives/dita/201312/msg00042.html (DITA, uploaded 22 November 2013; updated 7 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00043.html (HTML, uploaded 22 November 2013; updated 7 December 2013)
https://lists.oasis-open.org/archives/dita/201312/msg00044.html (PDF, uploaded 22 November 2013; updated 7 December 2013)
https://lists.oasis-open.org/archives/dita/201311/msg00173.html (DITA-OT plug-ins, uploaded 22 November 2013)
[skipped discussion of this to let Eliot rest his voice]
13121: Reuse a structural specialization as a domain (Priestley; Reviewers: Robert Anderson, Kris Eberlein, Bob Thomas)
Updates provided to reviewers on 28 November 2013
https://lists.oasis-open.org/archives/dita/201312/msg00045.html (DITA & HTML, uploaded 9 December 2013)
Michael gave an overview; this proposal allows you to pull elements from another structural specialization by referencing them in your shell. There's no impact to processing rules except for conref and keys stuff. It's related to 1.2 domain dependency work; he had to reword domain and @ dependencies from 1.2. The major change since stage 2 is language around how you assemble specialization, there's now a dependency on domains rather than just the structural spec; addition of '+' and '++' language for specifying domains and structural specializations. late additions were addition of XSD language, done by Eric Sirois.
Eliot; is ++ really required?
Michael; yes, there is a difference in how it's processed from generalization logic. if you have a dependency on a domain, it's valid to generalize to one level up, e.g troubleshooting incorporating 'UIcontrol' combination of ancestor and domain. You can't do that for structural specializations; the ancestor of a valid target is not itself a valid target. So it has to be done by looking at domain and class attribute.
Eliot; what are the processing expectations? My concern was it's a bit like 'simon says' syntax. No processor fails if you get them wrong, but your document is invalid.
Michael; it only affects generalization, but DITA says we can reliably generalize things; it usually doesn't matter, but when it does, it does.
Kris; Eliot, you're comfortable with proposal?
Eliot; yes
Scott; Eliot, what impact does this have on RelaxNG proposal?
Eliot; That proposal needs to reflect this one, but it doesn't affect how modules are constructed.
Resolution; this proposal will be voted on next week
13097: New troubleshooting topic (TechComm SC; Reviewers: Hackos, Dawn Stevens)
https://lists.oasis-open.org/archives/dita/201311/msg00057.html (HTML, updated 11 November 2013)
https://lists.oasis-open.org/archives/dita/201311/msg00058.html (PDF, updated 11 November 2013)
https://lists.oasis-open.org/archives/dita/201311/msg00059.html (DITA, updated 11 November 2013)
Bob Thomas gave the update on changes made since the last discussion on this. There's been some loosening up of previously very tight content model, which allowed optional 'title' (for when there were multiple solutions) and * (instead of ?) for cause and remedy elements (for when there's no known remedy). Also, he made some changes to comply with 13121 as it developed
Nancy; as a reviewer, I followed the changes and thought they all made sense.
Resolution; this proposal will be voted on next week
meeting closed at 12:00
-- Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]