dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 4 Januaryr 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Sun, 9 Jan 2022 19:17:09 +0000 (UTC)
Submitter's message
ActionItems:
1. Kris will send out email to dita-users & dita-comment saying we're thinking of removing classification maps
y=================================================
Minutes of the OASIS DITA TC
Tuesday, 4 January 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy
Business
========
1. Roll call
Regrets: Robert Anderson, Scott Hudson
2. Approve minutes from previous business meeting:
21 December 2021
https://lists.oasis-open.org/archives/dita/202112/msg00045.html (Lawson, 28 December 2021)
https://lists.oasis-open.org/archives/dita/202201/msg00004.html (Eberlein, 04 January 2022)
Kris moved, 2nd Frank, approved by TC
14 December 2021
https://lists.oasis-open.org/archives/dita/202201/msg00003.html(Harrison, 04 January 2022)
Kris moved, 2nd Keith, approved by TC
3. Announcements
- Convex; most presentations will be in person, but sopme online, no help needed from TC at this point, may include discussion of toolkit?
4. Action items
[updates only; see agenda for complete list]
14 December 2021
Robert: Add @outputclass to colspec COMPLETED
Kris: Respond to original poster on dita-comment about updated grammar files for DITA 1.3 errata COMPLETED
Kris: Post to dita-comment and dita-users about TC considering removing anchor and anchorref COMPLETED
Frank, Kris, Robert: Consider usage of the many ways that we refer in the spec to something being determined by an implementation IN PROGRESS
Kris: Post to dita-comment and dita-users about the TC considering removing "has" elements and subject relationship table COMPLETED
5. Final status: Review E (table elements)
https://lists.oasis-open.org/archives/dita/202201/msg00005.html (Eberlein, 04 January 2022)
- Kris; not much to talk about, we've handled all but 4 comment, all info in the wiki page
6. Review F: Attributes used on table elements
https://lists.oasis-open.org/archives/dita/202201/msg00000.html (Eberlein, 03 January 2022)
Open through 10 January; deadline will not be extended.
- Kris; this is a small review, after discussion in last call.
- Gershon; it is fairly small; review shouldn't take too long to get thru.
- Dawn; very straightforward
- Kris; sometimes stuff in complex tables doesn't make as much sense as we'd like it to; derives from fact that it's a translation of OASIS exchange table model (with some additions for accessibility), which isn't straightforward or as well-designed as we'd like.
- Dawn; that's what I thought.
- Kris; I grouped the @s in specific groups; if you look at PDF of draft spec, there's a master list of @s alphabetized. In future, we need to discuss the most user-friendly way to group them. For editing purposes, I needed to group them in order to make descriptions parallel. any thoughts?
[none]
7. Considerations for removing classification map and classification domain
https://lists.oasis-open.org/archives/dita/202112/msg00019.html (Eberlein, 09 December 2021)
https://lists.oasis-open.org/archives/dita/202112/msg00021.html (Joseph 13 Decemver 2021)
https://lists.oasis-open.org/archives/dita/202112/msg00022.html (Doherty, 13 December 2021)
New: At least two companies, Elucian and Kaplan, are using this
- Kris; currently expecting to remove these from spec and put in Github repo, for 2 reasons:
1. it's pretty difficult for authors to use this map; if they get integrated into primary maps, it makes them cluttered and hard to use (IBM authors revolted against using them ~2007-2009, and we . don't know if anyone is using them, except for zoomin).
2. classification map is part of base DITA, but it's only integrated in tech content.
OTOH, it's the only standard mechanism for associating topicrefs with subjects. It would be nice to define metadata in subjectscheme maps, rather than in topic prologs. One possibiity is to introduce an @ (subjectref?) that could be appplied to topicrefs, but it would be an abuse of keys,...
- Eliot; thinking about @subjectref on topicrefs, it would make it straightforward to define a subjectmap as a peer map, seems like a pretty clear solution to me..
- Kris; so we'd be proposing another use of keys?
- Eliot; basically, a @subjectref with values being keyrefs; since keyrefs can go cross-deliverable.
- Kris; so you think we could introduce a new @?
- Eliot; yes, if value of the new @ is keyref(s), it would work well in that context,
- Gershon; if we remove this domain, we don't need a workaround; the reasoning is that CCMSs are being integrated with ontology systems that do the handshaking at publishing time to make the right thing happen. I'm not convinced we need a way to map a bookmap to a subjectscheme. So not sure we still need it in DITA?
- Kris; yes, it's in heavy use for values for attributes, so it would be a drastic change. Use case I'm referring to is not for handling ontologies or taxonomy, but for small users, and use case for associating metadata to topics, without hardcoding them in topics or map. Users want to handle it in a variable way, similar to keys from 1.2. so they can define stuff in a subjectscheme map, and reference it from the main map. It's a much more slimmed down use case.
- Stan; I really like the proposal; it has nice simple logic and will appeal to smaller groups.
- Kris; we could tackle this in multiple pieces; do we remove, and if so, do we replace?
- Gershon; so if we do both things, do we add it in techcomm but not on base?
- Kris; I think it makes sense to have it in base. and have it ripple into techcomm.
- Gershon; ok
- Kris; do folks know of any implementations that are using classification maps? I know only 2, both in higher ed arena, where the needs are the clearest.
- Gershon; I don't think Zoomin has any customers that go that far, my clients aren't using it.
- Kris; folks using Zoomin mostly build spreadsheets; it would be good to reach out to Joe Gelb and find out what the impact would be.
- Eliot; at Servicenow, we use spreadsheet approach.
- Gershon; that's what we doo for our clients that use Zoomin.
- Kris; does Ixiasoft have processing for the spreadsheets? They give writers ability to view all taxonomy terms, and they drag&drop them into map being published, which adds them into the prolog. Then Zoomin has a process to pull them out and mimic what spreadsheet is doing.
- Eric; on product-specific stuff, we're just a pass-thru, in Eclipse environment they're put into individual topics.
- Kris; except for Zoomin, and only if they're using classification maps behind the scene. If we remove those maps, I'd like to provice a simple mechanism to associate subjects with topics, and allow for processing expectations. Shall I send emails out to Joe Gelb and post on lists that we're thinking of doing this?
- Zoe; I don't think we need to keep it, but I remember one person on the list who did say 'please keep it' ...
- Kris; I don't remember that, and they could always create their own doc shells to put it back in.
***ActionItem: Kris will send out email to dita-users & dita-comment saying we're thinking of removing this.
8. (Continuing) Spec terminology: Implementation-dependent / implementation-defined
https://lists.oasis-open.org/archives/dita/202112/msg00004.html (Wegmann, 04 December 2021)
Implementation-specific, implementation-dependent, etc.
https://lists.oasis-open.org/archives/dita/202201/msg00006.html (Eberlein, 04 January 2022
[Kris started by going over her latest email]
- Kris; everyone please look over the attached HTML files; we might have to get to a point where we have to define what an 'implementation' or a 'processor' is. Thoughts?
- Frank; I'm glad you sent out the file, to get a feeling for where it's used, and where we need to think about it. 2 things;
1. Do we need a definition, even if it's somewhere else?
2. Is that something that's only relevant for only normative sections of spec, or for other places also?
- Kris; if we do it, needs to be thruout the spec. Also, in places where I brought up normative statements, we can't adopt W3C terminology because it doesn't align with OASIS specs.
- Frank; but there's places where it's defined differently, do we want to refer directly to W3C?
- Kris; I'd like to make spec language as consistent as possible; there's an issue is how m,uch effort it would take, but I'd like to make it as standard as possible.
11:50AM ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]