Document Name: DITA TC Minutes 12 August 2025
Description
ActionItems:
1. Robert will fix grammar files to include a module for dita in base
spec.
2. Kristen will make that change to spec. and add a comment to github issue
(already done by Robert)
to description of how non-link items can get turned into links using keyref
3. Kristen willl update prop topic table in response to Chris P's first
dita-comment question, Robert will review the change.
4. Robert will give some thought to Chris P's second dita-comment question,
and bring it back to the call.
===============================================
Minutes of the OASIS DITA TC
Tuesday, 12 August 2025
Recorded by Nancy Harrison
link to agenda for this meeting:
https://github.com/oasis-tcs/dita/wiki/Previous-agendas
Attendance:
===========
Robert Anderson, Kristen Eberlein, Nancy Harrison, Scott Hudson, Bob
Johnson, Zoe Lawson, Christina Rothwell, Eric Sirois, Stan Doherty
Business
========
Regrets: Frank Wegmann, Christina Rothwell, Dawn Stevens
1. Approve minutes from previous business meetings
Minutes, 05 August2025 Taken by Nancy Harrison
https://groups.oasis-open.org/discussion/dita-tc-minutes-5-august-2025-uploaded
Kristen moved, 2nd Scott, approved by TC
[Minutes, 03 June 2025] Taken by Nancy Harrison
https://groups.oasis-open.org/higherlogic/ws/groups/c2c11e3a-c9cd-43d9-840b-018dc7cd5db9/documents/meetings/document?document_id=72849
Kristen moved, 2nd Scott, approved by TC
2. Announcements
- Boston DITA user's group, 13 August 2025 at noon ET:
"Tool-independent migration practices" by Stan Doherty Zoom Meeting
https://us02web.zoom.us/j/83801120436
Meeting ID: 838 0112 0436
Passcode: 700529
- Deadlines for speakers call:
- DITA Europe 2026
- ConVEx 2026
- DITA-OT Day 2026
3. Discussion items from Jarno/GitHub issues
a. Should we have a grammar file / schema related to the element in the
base package, and if so, how do we make that happen?
952 https://github.com/oasis-tcs/dita/issues/952
- Robert; content for dita element is only defined in techcontent, even
though we define it in the base spec., but if an element is listed in base,
should be defined in the base. I think the right thing is to create a
module that defines the element, without putting it in a document type
shell. that would regularize it.
- Kristen; I think this was an oversight in 1.2, when we split up folders
with grammar files, and it was an oversight in 1.3 that we didn't build a
module in base spec for dita element. The grammar files for it are only in
techcontent, Any other comments about ditabase?
- Scott; makes sense to me
- Robert; anyone using this doctype?
- Scott; not at ServiceNow.
- Zoe; we used it to solve very specific purposes but no more.
- Eric; we don't use dita at all, because it doesn't have an ID element.
- Kristen; typical use of ditabase is nasty, e.g.,using it instead of
ditamap to build hierarchy; for warehouse type topics; for multiple topics
in a single file; or a shell for reusable components. I'm not hearing any
opposition to Robert's suggestion. Anyone concerned with us creating
modules but no doc type shell, and having the doctypes shell reference
modules in base?
- Scott; would it hurt to add ID @ to it?
- Robert; the reason an @id was left off was to classify it as not a topic,
it would blur the line between it and a topic if added @id, and we don't
want it to be a real element.
- Kristen; that would be a whole can of worms.
- Scott; ok, better not to.
[consensus on this change]
***ActionItem: Robert will fix grammar files as outlined above
b. How can we improve the language (and/or what is actually allowed)
for turning non-linking elements into links with keyref?
954 https://github.com/oasis-tcs/dita/issues/954
- Robert; this was really meant for term element, so you could turn term
into a linking element even though it isn't a linking element. Can that be
extended? what does it mean when we say 'can become a link'?
- Kristen; yes, I can see the point; @keyref could be bound to any number
of things that wouldn't be reasonable.
- Robert; and with edge cases, could be bound to anything, some of which
wouldn't make sense. he's right.; we need to use better language than
'become a link'.
- Kristen; original intent was to talk about turning elements like term or
keyword into a link; we weren't thinking about turning an image, e.g., into
a link.
- Robert; not sure I understood you; if I have an image as a keyword, for
today, it becomes a text link and the link is a downloaded image.
- Kristen; and that's not what we meant.
- Robert; right, we thought of a PDF, but not for an image. I would expect
an image to be ref'd from a picture of that image.
- Kristen; this is an edge case; there are much better uses that people
would not use a keyword element for.
- Robert; right, but you can use that markup, so what do we do in the spec?
we need to pin down what this would resolve to; how it gets rendered in a
browser is up to the processor. Does it get rendered in a browser? probably
yes.
- Kristen; we have 2 choices
1. we could re-craft the last phrase in the sentence 'all links to ...'
to be more specific and prescriptive
2. add a wiggle room sentence for processors.
- Robert; but it needs to resolve to the same thing for everybody; one app
could render it as image, another as a download link; becomea a link, how
they render is is variable.
- Kristen; so I'm suggesting we leave sentence as it is, but add a
following sentence about how the link is rendered is
implementation-dependent.
- Scott; that's pretty consistent with other language in spec.
***ActionItem: Kristen will make that change to spec. and add a comment to
Github issue (already done by Robert)
4. Items from dita-comment list
a. Question about DITAVAL prop specifications with @val but no @att,
Chris Papademetrious, 30 May 2025
https://groups.oasis-open.org/discussion/question-about-ditaval
- Kristen; question is about table in spec description of prop, which seems
to be missing information that is implied by later text
- Robert; no, I think example might not be valid; it's an unspecified valid
condition
- Eric; we use something like that; any filtering @ with broken test would
get excluded.
- Robert; that's a valid interpretation, looking at this, but not correct.
- Kristen; we need to add another row to table above that says any @prop
that specifies only @val is ignored. I wonder if we reworked this topic in
1.3 and missed this row.
- Robert; no, I don't think we ever discussed it.
- Kristen; but a prop element that specifies only a @val is ignored, we
need to add it to the table.
- Robert; we also need to add a line for it about processing expectation;
should be an error condition.
***ActionItem: Kristen willl update prop topic table, Robert will review
the change.
b. [question about DITAVAL prop specifications with @val that targets
group name, Chris Papademetrious, 30 May 2025
https://groups.oasis-open.org/discussion/question-about-ditaval-1
- Kristen; is he saying that this can happen on groups ; also ref to the
prop element
- Robert; I think we do say what he's asking us for, so not sure what the
issue is.
- Kristen; he's refering to the example provided; but he asks us to
specifically document it, and it's already there. What I'm wondering is, if
we were to look at the section on processing, under conditional processing,
do we say that?
- Robert; I'm confident that we do, here is it in the example, and it's
also in the spec, so I'm not sure what he's asking.
- Kristen; I'll respond and say it's already in the topic, and there's an
archspec topic that includes it also, not sure what he's missing. he may be
missing the entire archspec topic on groups.
- Robert; maybe it's a different condition. e.g., setting default for group
name, but not sure why you'd do that, I don't know why the example gives
this confusing way to do a straightforward thing.
- Kristen; in our example, or what he's writing in his email?
- Robert; I'm trying to find the actual text, and I can't. He's assuming
this means there's a rule, and we're not saying that; you can set
product=database, and we're not.
- Kristen; we need to take some time about this one, and what might need to
change in the spec.
***ActionItem: Robert will give this some thought and bring it back to the
call.
11:58 am ET close
Download Latest Revision
Public Download Link
Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2025-08-19 15:56:07
|