dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 15 August 2023 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Mon, 21 Aug 2023 21:15:42 +0000 (UTC)
Submitter's message
ActionItems:
1. Eliot will take a look at spec and see if we adequately address Dennis Troaca's examples; once we've done that, we need to respond to Dennis on dita-comment.
2. Nancy will update front page to address comment by Frank Ralf.
3. Kris will respond to email from Weiwu Zhang.
===============================================
Minutes of the OASIS DITA TC
Tuesday, 15 August 2023
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
===========
Robert Anderson, Stan Doherty, Kris Eberlein, Nancy Harrison, Eliot Kimber, Christina Rothwell, Eric Sirois, Leroy Steinbacher, Dawn Stevens, Bob Johnson
Business
========
1. Roll call
Regrets: Scott Hudson, Zoe Lawson, Frank Wegmann
2. Approve minutes from previous business meeting:
01 August 2023
https://lists.oasis-open.org/archives/dita/202308/msg00011.html (Harrison, 08 August 2023)
Kris moved, 2nd Dawn, approved by TC
08 August 2023
https://lists.oasis-open.org/archives/dita/202308/msg00014.html (Harrison, 11 August 2023)
Kris moved, 2nd Eliot, approved by TC
3. Announcements - none
4. Action items and volunteer tasks
[updates only; see agenda for complete list]
18 July 2023
Dawn: Check with Brianna on extent to which she's updated L&T for 2.0.
- Dawn; I sent brianna's comments to Scott, not sure what they're worth, but...
5. e-mails from dita-comment list
a. Key definition with key reference
https://lists.oasis-open.org/archives/dita-comment/202308/msg00003.html (Denis Troaca, 08 August 2023)
https://lists.oasis-open.org/archives/dita/202308/msg00017.html (Bob Johnson, 09 August 2023)
- Kris; this involves potentially variable text, or changing our rules... between 1.3 and 2.0
- Eliot; looks like, if there's an element but it doesn't have sub-elements, but a further item ref'd by a key does have them, do you pull those in? My gut reaction is 'no.'
- Robert; agree; if you hae keywords in original def, it won't pull them in.
- Bob; so we're saying child elements behave differently?
- Robert; no, they behave the same; if you already have a keyword element, don't pull another.
- Bob; but if you have a keyword without a value, and further down you have a keyword with a value, that value would be used?
- Robert; the mail includes multiple questions, if you have an empty topicmeta, and also if I have empty keywords, won't pull additional keywords elsewhere.
- Eliot; what's being pulled is the keywords element, not the individual keyword elements within it. even if the original keywords element is empty, it still won't be overwritten by keywords element in ref'd topic. If referencing element keywords element is empty string, then it isn't overwritten
- Bob; what about if there are no keywords element in referencing element, but keywords in ref'd element.
- Eliot; in that case you pull the keywords, but the email also talks about a different case, we described above, and both situations are presented as a single case, but it's two different cases, which are different results.
- Kris; right, it's two different examples, which should have 2 different results. So we haveuse case 1 and 2.
- Bob; but we need to clarify, because we don't talk about elements, just @s.
- Kris; we've made changes in 2.0, wrt text or link text addressed by keywords.
- Eliot; I know we have language about link text and its implications.
- Robert; there's a topic about processing keyrefs, but not this particular case.
***ActionItem: Eliot will take a look at spec and see if we adequately address Dennis Troaca's examples; once we've done that, we need to respond to Dennis on dita-comment.
- Kris; so we'll look at it next week to see what response to Dennis should be.
b. OASIS website: Info on DITA 2.0 hard to find, URLs broken
https://lists.oasis-open.org/archives/dita-comment/202308/msg00004.html (Frank Ralf, 10 August 2023)
- Kris; our PDFs for draft 2.0 spec have links that will eventually resolve, but they don't yet; they won't until we're in official stages. I can update the baae map so we have live links on covers of PDF, but I need a volunteer to update home page.
- Nancy; I'll do that.
***ActionItem: Nancy will update front page to address comment by Frank.
c. Addressing the Challenge of Linking to Collections in DITA -2.0
https://lists.oasis-open.org/archives/dita-comment/202308/msg00005.html
- Eliot; they don't understand DITA.
- Robert; this is what DITA maps are for..
- Eliot; you can certainly link to a topic group; if you put keys on topicrefs, you can link to any topic in a publication.
- Kris; and you're linking by that in that context.
- Eliot; it's not clear what their actual reqs are, or what they're trying to do. I recommend they post this on dita-users, not as a comment, but a question about how to use DITA.
- Kris; I think they don't understand how to do what they want to do, and it's not clear exactly what they want to do. It's a questio of how to select the right DITA mechanisms that do what you want to do.
- Leroy; he says 'entire collection', maybe it's HTML; if so, you get to root topic but have to follow other links to get to individual subtopics. It's not clear, from what is written, what he wants to do.
- Kris; it says 'grouping studies in a ditamap', so it's impossible to tell what the actual problem statement is.
- Dawn; if each case study is a chapter, you can't link to the chapter; you have to link to first topic in chapter, there's no way to cross-ref chapter.
- Eliot; but there is; if chapter element is functioning as topic head, if you put a key on it, then you can do it.
- Christina; I'm not familiar with our linking, but it looks like he wants to ref collection as single topic. I don't know how he has DITA set up, but it looks like he doesn't know how to do what he wants. It's more a usage question than a spec question.
- Kris; good to hear diff people's interpretation of it, pretty ambiguous. I'll suggest he go on dita-users,
***ActionItem: Kris will respond to email from Weiwu Zhang.
6. Concerns about and its rendering rules
https://lists.oasis-open.org/archives/dita/202308/msg00017.html (Eberlein, 15 August 2023)
- Kris; if there's a real question about how to determine what is/isn't an introductory context, how can it determine a normative SHOULD? I understand need to have consistent processing of abbreviated-form (a-f) and glossary elements; different processors do completely different things on how they render a-fs. My 2nd concern is that these rendering statements don't align with other rendering statements about linked text. Robert and I knew that when we redid the material.
- Eliot; what if glossary a-f was a titlealt in diff a-f? Then we could do it better.
- Kris; so that would mean redoing the specialization base. I don't know if, given content model of glossentry, we could do that without completely re-defining glossentry.
- Robert; I don't think so, and we'd need a domain of titlealts completely specific to that topic. It would make sense, but it's quite a big change.
- Eliot; in the mail, would this be in rendering expedctations sections?
- Kris; I want to put a separate section in spec about glossary mgmt and terminology, and put a-f in that. But just to solve this problem, maybe we should just get rid of the normative SHOULDs. But if we then look at base spec, there's the statement that processors MUST resolve .... even though the a-f element is essentially variable text that is rendered that's key- and context-based.
- Eliot; rules for what effective link text is, is different from how you choose to render a link; rendering can be different from what the actual link text has to be.
- Kris; this really isn't about rendering, it's about what is effective link text or variable text, not rendering processing. Maybe 'Processors should treat', rather than 'should render'.
- Eliot; processing rules for getting effective link text, are independent of whether it's intro text or not. but it's only when you get to 'is it intro text or not?' that you have to figure it out.
- Robert; we've got all these rules about how keys are supposed to resolve and a-fs are a bunch of exceptions. But we do have a handful of rules about rendering, e.g. monospaced and shortdesc. And a-fs are a combination of rendering and processing.
- Eliot; but once I've resolved a keyref to a glossentry, then I have access to everything in that topic, and I can render it anyway I want.
- Kris; so if we take out the normative language, then it doesn't matter what we say, doesn't conflict with base. But Robert says, not quite; it's a little more nuanced, some rendering has an impact on interoperability. how processors render elements in glossentry also has impact on interoperability.
- Eliot; I disagree; I don't accept that anyone can force any rendition on me.
- Kris; but we have a lot of content on rendering a-f element, if we change all that, will you have the same opinion?
- Eliot; procesing is about address resolution; gets me effective titles, link text etc; then we go to rendering, and I can choose to completely ignore that info. So we can say 'it would be nice to do this', but we can't say it's required.
- Robert; if people looked at it, many would have a different sense of what it means from Eliot
- Eliot; getting effective link text, and choosing how to render it.
- Nancy; so is it correct as it stands?
- Eliot; I don't think it should say SHOULD; if something is a rendering expectation, it doesn't make sense to have a SHOULD; it can't be normative.
- Kris; but we have rendering expectations that use normative language.
- Eliot; when is it appropriate to say SHOULD, and when it's not. in that case?
- Kris; how can we make a normative SHOULD when we dont define what intro context is?
- Eliot; but putting the language in spec, even without a SHOULD, gives it a fair amount of weight
- Kris; and can we give clues on how to evaluate intro vs. non-intro content? Some outputs are more amenable to rendering 'first occurence', which was the original sense of 'intro.' Any thoughts? I'll do one more go-around, with input from Dawn.
7. DITA TC wiki
[no updates; see agenda for details]
8. Review U: Overview of DITA
[no updates; see agenda for details]
9. Volunteer spec assignments
Assignment (https://wiki.oasis-open.org/dita/DITA-2.0-Backlog)
[TC went over current status of tasks on assignment list]
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]