Submitter's message ActionItem:
1. Kris and Robert will take the normative rules about generalizing when using @conref out of the spec.
y===============================================
Minutes of the OASIS DITA TC
Tuesday, 8 October 2024
Recorded by Nancy Harrison
link to agenda for this meeting:
https://github.com/oasis-tcs/dita/wiki/Previous-agendas
Attendance:
===========
Robert Anderson, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Bob Johnson, Eliot Kimber, Zoe Lawson, Christina Rothwell, Eric Sirois, Frank Wegmann, Leo Belchikov
Business
========
Regrets: none
1. Approve minutes from previous business meeting
01 October 2024 (Harrison, 07 October 2024)
https://groups.oasis-open.org/discussion/dita-tc-meeting-minutes-1-october-2024
Kris moved, 2nd by Scott, approved by TC
2. Announcements
Call for speakers: DITA-OT Day, 16 February 2025, Copenhagen, Denmark
https://www.oxygenxml.com/events/2025/dita-ot_day.html
H Call for speakers: DITA Europe, 17-18 February 2025, Copenhagen, Denmark. Deadline is 01 October 2024.
https://ditaeurope.infomanagementcenter.com/call-for-speakers/ Call for speakers: ConVEx 2025, 07-09 April 2025, San Jose, CA
https://convex.infomanagementcenter.com/call-for-speakers-2025/
3. Conref review: Ella Fitzgerald
Opening of review (Anderson, 17 September 2024)
https://groups.oasis-open.org/discussion/base-spec-review-ella-fitzgerald-all-about-content-referencing PDF
https://groups.oasis-open.org/discussion/dita-20-review-e-conref-uploaded Content Fusion review
https://fusion.oxygenxml.com/tasks/ngbco2onlce6jm39qa6r07d2bvgtohtl5c5in7ohj0nmkckr Update on review
Participation as of 01 October 2024
https://groups.oasis-open.org/discussion/participation-in-conref-review-as-of-01-october-2024 Trends?
- Robert; no real update, starting to work thru comments, nothing that needs to coem to TC
4. How to highlight conref rules?
E-mail from Anderson, 01 October 2024
https://groups.oasis-open.org/discussion/how-to-highlight-conref-rules
- Robert; we have rules scattered around in conref. How to do that best? One topic would be convenient but risks folks would miss them, so generally I prefer to keep them with the @ they're describing. And some @s have several rules, some just one, so a separate topic for each might be ugly.
- Eliot; challenge is to have a clear non-normative explanation of how parts fit together, but ahoving rules in the langref is a problem.
- Kris; it's another result of those topics having originally been ref @ topics in langref, we've moved them into architecture section, but not reworked them yet.
- Robert; e.g. there's the issue of how to use @conrefend, if you're using @conrefrange. Maybe Eliot's suggestion of a non-normative topic that lists all the rules, but has no normative statements.
- Nancy, and a link to that descriptive list from locations where it would be useful?
- Kris; should the @ be the attribute, or the the thing it points to?
- Robert; the topic titled 'conrefrange' is from the langref;
if we change the focus to conrefrange as an architectural concept, that's still where the normative rule beoongs
- Kris; I'd be happy to do a reorg to put the content in the right place.
- Robert; it would be good to have an editor's call about that.
- Kris; yes, and I'll be gone 3 days next week.
5. Question about conref and generalization
E-mail from Anderson, 24 September 2024
https://groups.oasis-open.org/discussion/question-about-conref-and-generalization
- Robert; Eliot thinks we should get rid of generalization rules for this; we've discussed this a couple of times;
- Kris; yes, now that we've gotten rid of @domains, it doesn't make much sense
- Robert; Eliot, do you have any further comments, and/or does anyone wants to keep it?
- Eliot; probably no more to say; without @domains, it doesn't make much sense, and processors can't even satisfy it, for the most part. but there's certainly no reason for it to be a requirement of the spec.
- Robert; we need to have language in spec that allows this to take place, but remove the normative requirement that it should be done.
- Kris; no one is suggesting getting rid of discussions of generalization, but just getting rid of requirement to do so. any objections to getting rid of requirement?
[no objections]
***ActionItem: Kris and Robert will take it out of the spec.
6. Question: @keyscope on subjectSchem
E-mail from Kimber, 01 October 2024
https://groups.oasis-open.org/discussion/question-keyscope-on-subjectscheme Response from Eberlein
- Kris; we discussed this last week. The answer to Eliot's question was 'yes, we very thoughtfully omitted @keyscope from subjectscheme (SS), I had some reservations because I saw use cases for it, but it was so fraught with difficulty because of the nature of SS, and Robert and Chris Nitchie (developer of @keyscope) thought implementing it would be a nightmare.
- Robert; reason it caused so much angst is that reuse keys for SS where they don't really function as keys. The issue was 'what impact would it have on @s defined in SS, could/should @S allow both values?'
- Eliot; for enumerated values?
- Robert; yes, that confused that, and so we took it out.
- Eliot; I can see that would have to be addressed, e.g., for purpose of enumerated keys, that's what you use. we use SS for taxonomies, to classify topics with our subjects, might also use them to drive editing, though probably not. So we need to include SS in our maps, and we need keyscopes; there's no way we can use SS without adding keyscopes. The real point is that the current 2.0 draft for SS says it uses base map, which includes @keyscopes, but the grammar files don't have them. So that descrepancy was what led to the question. So it was our lack of resources that prevented us from fixing it?
- Robert; Eliot's suggestion to say that 'this has no impact' is cute, but not sure what it might do. I don't know where it might have an impact; probably a question of how the tool is set up.
- Kris; Eliot, you want to have root element of SS map contain @keyscope?
- Eliot; yes. Now it's on the topic that's referring to the SS map, but can see use cases where it would need to be in the SS map itself, putting @keyscope on each ancester subject. The alternative is to generate SS from qualified keynames.
- Kris; I think it just comes down to the SS design trying to do too many things at once. It's basically flawed.
- Eliot; I wouldn't go to the mat on this given the fact that we can just get our result our own way. Since I can put a @keyscope on a mapref, within SS, I can still do what I need. We're now using SS; they're integrated into our pub maps.
- Kris; but they're not your actual pub maps. And you can put your @keyscope on your ref to the SS.
- Eliot; yes, but we don't have way of putting things within it, and we don't have the way to fix it.
- Kris; and if your SSs are being generated automatically from another system, they're an artifact to begin with.
- Eliot; we'd like to use SS since it exists, but there's nothing any tool does for us regarding SS maps except for enumerated lists.
- Kris; it's clear that we don't have time or resources to do anything on SS for 2.0.
- Eliot; I agree.
7. Action items
See Current action items
https://github.com/oasis-tcs/dita/wiki/Action-items
12 noon ET close
-- Ms. Nancy Harrison
---------------------------------
Nancy Harrison
Principal, Infobridge Solutions
Nancy Harrison (Personal)
Portland OR
978-505-9189
---------------------------------