Submitter's message ActionItems: none
y===============================================
Minutes of the OASIS DITA TC
Tuesday, 15 April 025
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, Christina Rothwell, Leroy Steinbacher, Dawn Stevens, Frank Wegmann, Leo Belchikov
Business
========
Regrets: Zoe Lawson, Eric Sirois
1. Approve minutes from previous business meeting
1 April 2025
https://groups.oasis-open.org/discussion/dita-tc-minutes-1-april-2025-uploaded
Kris moved, 2nd by Scott, approved by TC
2. Announcements; none
3.. Report back from ConVEX
- Scott; great conference; a lot about using AI to look at how your content is being created and used; IBM had a good one; interesting way of looking at content gaps.
- Robert; this has same number of AI and IIRDS presentation, but didn't seem so overpowering
- Dawn; right, had an IIRDS booth, but presence didn't seem as heavy since there are more than twice as many total sessions, we wanted to let US market know about IIRDS.
- Kris; we started talking about IIRDS about 2013/2014
- Eliot; because there's not a directed IIRDS graph for german content, makes it easy to use
- Bob; I've been working on integrating IIRDS, more effort coming from IIRDS side to integrate with DITA, I've been using classification maps, people say they're not useful, but they are for me. IIRDS wants to integrate with DITA world in US
- Kris; but for 2.0 we got rid of classification map and domain.
- Robert; a classification map is just a map plus that domain. but if you found something in it, you can keep using it, The spec never defined any processing, that's why we got rid of it; if you have used it, you can keep doing so.
- Kris; we got rid of it, because its design never had its markup updated wrt 1.2. But in 2.0, we have new @s and that @ will be available in maps and will serve same purpose as classification domain did. more about ConVEX? Dawn?
- Dawn; about 235 attendees, about 20% over previous year, mostly because it was in the bay area with 70 locals attending. I'll have to look at numbers, still growing back after pandemic. rooms were crowded, presentations were good. I was happy.
- Eliot; nice to see people talking about writing, rather than just tring to justify existence of DITA.
- Dawn; our org opened up an individual membership towards that object; we're planning to do more quarterly events with a writing focus. I'd like to make the conference more diverse, less DITA-specific, that was part of name change. So, next year in Pittsburgh.
4. Walk through spec review feedback
DITA addressing
id attribute
Bob Johnson
https://groups.oasis-open.org/discussion/fw-external-fwd-dita-review-content-from-bob-johnson-id
- Bob; Eliot had some comments, which I'll incorporate.
- Robert; I agree with Eliot's comments.
- Bob; last sentence about paragraph 2; recommended moving it into another para. suggested we ref a resource that defines what an XML name token. Paragraph 3 needs no discussion. Wrt #4, MIGHT, is it normative in this situation> if not, it might get changed
- Robert; but 'might' means the same where it's normative or not
- Eliot; , I might use 'could, or can but dorsn't change things
- Kris; Robert is right, it's kind of meaningless, we don't want to avoid using word everywhere, it uses a lot of energy. , then OASIS changed the rules on us.
- Robert; if we can replace it easily, great, but we won't to a lot of effort to do so.
- Bob; I thought the terms were only to be used in a normative way
- Robert; no, IF they're used in a normative way, must be upper-case.
- Kris; if you look at TC spec rather than Jarno's, you can clearly see the difference, including a sidebar that indicates normative statemenrts.
- Bob; next question, for Paragraph 5, 'excluding child topics' that wasn't clear to me. identifier is only parent topics not any child or descendent topics
- Robert; yes, as suggested by your suggested rewrite. once you hit barrier of a new topic, that ends the scope of @id. This is a difficult sentence.
- Kris; @id within nested DITA topics is simply difficult to explain clearly and unambiguously; we can't do better without many examples, and I don't know whether we want to provide examples.
- Robert; I agree.
- Eliot; even a single example would go a long way here.
- Kris; Bob, your comments were helpful.
- Bob; I tend to be sparing in use of notes, but as per my comment, this note seems important and I'd consider taking it out of note and making it a heading so it's not so easy to overlook
- Kris; so you're referring to this very last note; it's parenthetical, and doesn't appear that way in the spec. we can consider whether to do that or not.
- Robert; we definitely have something about this in the footnote element, so we might want to add it here as well. I don't think it's worth a heading, but not sure how to make it more prominent without one...
- Kris; thanks Bob, for these comments; Robert and I will rework content now that we have the reviews?
Indirect key-based addressing:
Bob Johnson
https://groups.oasis-open.org/discussion/fw-external-fwd-dita-review-content-from-bob-johnson-indirect-addressing
- Bob; somem confusion over indirect and screen-key variables
- Robert; there is content about processing key refs to generate text, which could be for variables or on its own; can use text replacement with or without a link.
- Kris; are you suggesting us moving using keyrefs to generate link text out of link text and into a peer section?
- Robert; that makes me nervous; rules for resolving it it are same
- Kris; at end of day, for every keyref that's used to create text, there's an actual keydef that indicates addressing
- Bob; think I understand what you're saying, but not completely sure. It seems to me we should discuss this as part of both a topic ref and the keydef.
- Eliot; but we don't mean just topicref, we mean topicref and any specialization of topicref that contains keydefs.
- Robert; and it's hard to make that clear, and there are hundreds of places in the spec where we do that, we use 'topicref' for topicref and any specialization of it, and use 'topicref element type' to mean only topicref. Any topicref element that allows the @keys allows for this.
- Robert; in 1.0 spec, this was very inconsistent, so we tried to regularize it.
- Kris; and it introduces cognitive dissonance. It has to be everywhere or nowhere, and we decided to state clearly up front that 'topicref' refered to the larger set, and 'topicref element type' when we were specifically only that.
- Bob; so topic about keyref @ was kind of long; I think we could simplify shortdesc and move ordered list into the abstract
- Robert; so you when you say 'ordered list', you're actually referring to just the long comma-separated list?
- Kris; yes, it's not a very concise shortdesc...
- Bob; next comment on cross-deliverable linking, seems a bit buried.
- Kris; actually is a topic-level item, so unless we were to move it out of key-based addressing, would be hard to change it.
- Robert; right, we could change its prominence only if we move these out of indirect key-based addressing, and we can't do that; only way to do it would be to re-work this would be to do a basic part and add other topics for the various parts.
- Eliot; this is in context if you have a keyref that refs another key definition, but maybe it's not so clear
- Bob; I found it not so clear.
- Kris; we'll look at it. It's hard reading next couple of comments out of context? within 'Processing key references'? maybe in 'navigation links and resources'?
- Eliot; @resourceid isn't specific to keys... for 2.0 we added that it replaces copy-to; this is what I want the effective anchor to be in this topic for this context. and that's a necessarily fuzzy thing.
- Kris; I think we should just skip over this till we can figure out what topic this refers to.
- Bob; name of a scope being referenced is unclear. Without the quotes, it looks like an incomplete sentence. but they share a keyscoope that is NAMED 'using' without the quotes, it's incomprehensible.
- Kris; Eliot, any comments?
- Eliot; even use of string keys, it's addressing ..., but the use of keys just for getting strings is worth discussing somewhere specific. I don't want to be really specific, only note the difference between a string key and a non string key is that it references an outside text, otherwise they're completely the same. The question is, is it a description?, or guidance on how to use DITA?. Spec is meant to be the first, not the second.
- Kris; we are not writing the spec as a user guide, but a definition, and a guide for processing. More TC members are now DITA users rather than DITA implementors. Once 2.0 is out the door, we can turn to providing more user-focused info. Is it now time for TC to pay more attention to IIRDS? iI so, what will that look like? We did go thru a discussion with OASIS, and they were willing to give a free membership to a single IIRDS person/company if they were to be an active member of TC
- Bob; There's strong interest from IIRDS side on collaborating with DITA TC.
- Kris; did IIRDS consortium folks have any ideas on what that collaboration would look like?
- Bob; no, they now would just like to talk about more collaboration and integration with DITA.
12 noon ET close
ActionItems: none
-- Ms. Nancy Harrison
---------------------------------
Nancy Harrison
Principal, Infobridge Solutions
Nancy Harrison (Personal)
Portland OR
978-505-9189
---------------------------------