Re: [dita] Groups - DITA TC Meeting Minutes 14 December 2021 uploaded

[Kristen James Eberlein <kris@eberleinconsulting.com>]

Happy New Year, Nancy!

A correction (highlighted in red)

- Nancy; so we'll be considering removing them even though they weren't previously deprecated?
- Kris; yes
***ActionItem: Kris will post to dita-users and dita-comment about this.

Rationale: We will wait to see what sort of feedback we get from IBM, dita-users, and dita-comment before making the final decision.

Best,
Kris

On 1/3/2022 7:27 PM, Nancy Harrison wrote:

Submitter's message
ActionItems:
1. Robert will make change to add @outputclass to colspec as part of hot fix branch and respond to commenter.
2. Kris will post to dita-users and dita-comment about deprecating anchor and it's associated attributes.
3. Frank will keep looking at places in the spec for this, including other wording. It's probably a good time for Frank to get familiar with how we deal with normative statements. given his new role in LwD. And Robert and I can start looking in spec for these terms. we should improve this for 2.0.


y=================================================
Minutes of the OASIS DITA TC
Tuesday, 14 December 2021
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Alan Hauser, Scott Hudson, Gershon Joseph, Eliot Kimber, Zoe Lawson, Chris Nitchie, Keith Schengili-Roberts, Dawn Stevens, Frank Wegmann


Business
========

1. Roll call
Regrets: Eric Sirois


2. Approve minutes from previous business meeting:
7 December 2021
https://lists.oasis-open.org/archives/dita/202112/msg00020.html (Harrison, 10 December 2021)
Kris moved, 2nd by Scott, approved by TC


3. Announcements
Chris Nitchie is leaving TC; the TC expressed its regret and gratitude to him for the his tremendous contributions over the years of his participation.


4. Action items
[no updates; see agenda for list]


5. Feedback on dita-comment list
Output class attribute on colspec element
https://lists.oasis-open.org/archives/dita-comment/202112/msg00000.html (Toshihiko Makita, Antenna House, 13 December 2021)
- Kris; this was feedback from Antenna House; @outputclass, though appearing in spec, isn't available on colspec; Robert suggested a hot fix for this.
- Robert; it's clear that spec says @outputclass is there, but grammar files are missing it, we can put out a hot fix for 1.3, but we won't put out an errata.
- Kris; I'd advocate a hot fix, which won't break anything. any objections?
[none]
***ActionItem: Robert will make change to add @outputclass to colspec as part of hot fix branch and respond to commenter.


6. Deprecate and related attributes
https://lists.oasis-open.org/archives/dita/202111/msg00054.html (Joseph, 24 November 2021)
https://lists.oasis-open.org/archives/dita/202111/msg00055.html (Anderson, 24 November 2021)
https://lists.oasis-open.org/archives/dita/202111/msg00056.html (Anderson, 24 November 2021)
- Kris; Gershon suggested we remove anchor and related @s from 2.0
- Gershon; I don't think they're being used by anyone, and they're just in the way; now's a good time to do it.
- Robert; main thought is we need to explicitly say what's being removed; i.e., anchor, anchorref, and @anchorref. The other thing is that we don't know if anyone outside IBM is using it; we don't know how widespread use might be. It was for Eclipse, so anyone using Eclipse might be using it.
- Kris; we'd have to query on dita-users and dita-comment, as well as let IBM users know before we remove it. We tend to do that before removing things, though. Thoughts from other members on this?
- Eliot; I'm trying to see if there's any justification; my instinct at the moment is that they represent such a narrow use case, that it doesn't need to be codified in spec. I have no objection to removing it; users could always add their own specialization of it.
- Scott; and wrt ServiceNow, those elements are always constrained; we don't use them.
- Kris; any other thoughts?
[none]
- Nancy; so we'll be removing them even though they weren't previously deprecated?
- Kris; yes
***ActionItem: Kris will post to dita-users and dita-comment about this.


7. Spec terminology: Implementation-dependent / implementation-defined
https://lists.oasis-open.org/archives/dita/202112/msg00004.html (Wegmann, 04 December 2021)
- Frank; looking at the latest spec review, I wondered which one/when we should use them. Are there areas where this should apply more than previously? implementation-specific (i-s) refers to specific feature, but implementation-dependent (i-d) is defined by W3C; they say it's where a feature's behavior may vary from one vendor to another, for an i-d feature, an application is allowed some flexibility and must be documented. I checked our spec and found not many instances of this term.
- Kris; there may be more instances, but not easily findable.
- Frank; is there a need to be more precise? do we need to check spec, and should any of these terms be used specifically?
- Kris; wrt the the W3C definitions, should we make more normative statesments?
- Robert; consistency would be good. People have used different terms over the years; there was some cleanup in 1.3, but never completed.
- Kris; if we could do this without a huge time effort, that would be good....
- Frank; also, are there places where it hasn't been used before, but should be?
- Kris; certainly likely.
- Robert; lot of i-d situations are around error recovery; generally, if the spec doesn't prohibit it, it's allowed. If you don't give a normative rule about something, then people can do it differently. we need to acknowledge that.
- Kris; another place, beside error recovery, is rendering
- Robert; yes, rendering is usually left up to an implementation.
- Frank; at this point implmentors have a longer leash.
- Kris; people, please think about this.
***ActionItem: Frank will keep looking at places in the spec for this, including other wording. It's probably a good time for Frank to get familiar with how we deal with normative statements. given his new role in LwD. And Robert and I can start looking in spec for these terms. we should improve this for 2.0.


8. Review E: Table elements
https://lists.oasis-open.org/archives/dita/202112/msg00025.html (Eberlein, 14 December 2021)
Kris; opening up another review today; just table and -simpletable; will run thru next Monday.
- Dawn; reading it this morning; wanted to see all of the simpletable @ topics, would be nice to have a bit more added to review; would be useful to be reading the @s at the same time.
- Kris; Robert, what do you think?
- Robert; as I'm hearing that , seems obvious, so don't know. now consolidated in two topics in spec, so we could have those in, don't know how ditaweb will handle that though. should be rebuild review and add those topics; they're quite long, and still need a bit of cleanup
- Kris; right, we know we're not done on those topics yet; suggest that if you wanat to look at them, look at full copy of DITA spec, so links will be live.
- Dawn; well that's what I ended up doing.
- Robert; if you're doing that, better to put comment in table element topic, rather than trying to remember it later
- Kris; for later reviews, we'll try to see if we could include @s also
- Zoe; have had trouble reviewing @ sections; having a bit more guidance on @s section would be good.
- Kris; we'll se what we can do for next review. knew we didn't want to include @ topics until we'd done cleanup on them
- Robert; trying to get thru reviews in timely fashion, dancing just ahead of the curve.
- Zoe; know it's tricky because we used to list all of thme and now we reference them. sometimes get confused about pointing to family, ors ubset, or @s in this element.
- Kris; we'll move this ahead on our priority list, and can talk about @ design and why it's done that way.
- Robert; current one einformed by HTML spec; most HTML uses basic set of @s plus some unique one; we've tried a few variations every one has pros and cons.
- Kris; hopefully, this also is moving us toward a way to have a listof all @s a-z.
- Robert; have a prototype,, but waiting till spec is stable. in past we've had an appendix withalphabetical list of elements; want to have one like that for @s, would be a really handy reference.
- Kris; and something users have been asking for for years.


9. Updated status from review C
https://lists.oasis-open.org/archives/dita/202112/msg00026.html (Eberlein, 14 December 2021)
- Kris; most comments have been handled, have final version of spec; trying to not get too far behind. would suggest you look thru the review comments and check and see if there's any final disposition that doesn't look right and get back to us on it.


10. (Interim) status of review D
https://lists.oasis-open.org/archives/dita/202112/msg00028.html (Eberlein, 14 December 2021)
Summary of comments so far
Feedback from participants? Any things we could be doing better?
Processing expectations for @keyref in the context of a subject scheme and schemeref
https://lists.oasis-open.org/archives/dita/202112/msg00029.html (Eberlein, 14 December 2021)
- Kris; please look at this; there are still some open issues, determining effective @ values. lot of questions about why things were designed the way they were, some confusion about some of the SS elements that were intended more for display (see email)
- Robert; Zoe, one fo yiour comments was a question, for which the answer was 'yes', a lot of SS elements that were for edge cases, which is why we're thinking of removing them... anone still thinking of doing D?
[Gershon, scott, Eliot]
- Kris; SS has some important draft-comments; one is effectively a comment Chris had in 2015 about 1.3, and we didn't covr it for 1.3, but we should for 2.0. Stan , this also relates to a comment you made, about key resolution not generating variable text for links.
- Eliot; what is statement that spec currently makes?
- Kris; it doesn't make a normative statement, no expectations for keyrefs in SS, tend to be implicit.
- Robert; problematic text was if you put keyref=windows, should result in text or links, this is a diff kind of key; used key architecture for something that doesn't work like keys; failed to really explain that.
- Kris; but we have topic in arch spec about extending SS, such a diff functionality from anything else with keys
- Robert; should be diff elements/@s, but it never got changed for 2.0, so it won't change now. section inarch spec shoud stat with a cavaet, but it won't so...


11. Removing the has elements from DITA 2.0
https://lists.oasis-open.org/archives/dita/202112/msg00018.html (Eberlein, 09 December 2021)
- Kris; suggested this; defined as part of SS, don't think they have much utility, clutter up SS maps, could easity create a domain specialiization and put it in the github repo
- Frank; when I first saw SS, thought that you could control @ values, but couldn't see what that would be useful, so now I have an idea, now that we're removing it
- Eliot; intent was to let you define ontologies, how concepts relate to each ooother and are related, with markup defined, you could define knowledge in the same way RDF allows you to do that like SKOS, think that was Erik's intent. my responseit 'dita's the wrong place to do that; there's already a standard that does that; might have made sense 15 years ago, butnot now.
- Kris; not suggesting we remove ontologies
- Eliot; a taxonomy is a hierarchy, and ontology is al the various relationships, we shouldn't be doing that in dita
- Kris; sent to dita-usrs about using controlled values; got only on response and they don't use the 'has' eelements. if we get rid of 'has' element, do we also get rid of subject relationship table. Robert in favor, I'm on the fence.
- Eliot; how is a subject relationship table diff from a regular reltable?
- Kris; that's the one thing that might make me want to get rid of subject relationship table.
- Eliot; what was your client using it for?
- Kris; Allstate has a voice-activated system that helps their agents in doing search; a large taxonomy, and thing were related to each other via subject relationship tale. but later the SS-driven implementation was dropoped in faovor of RDF.
- Eliot; if ou're contributiong to a website, there's lots of tools to ouse tha are better that dita.
- Gershon; with exeption of clients that's using zoomin, tend to use an ontology DB, so we don't use dita.
- Robert; the tools that drove this design at IBM were abandoned a decade ago, so we should get rid of these.
- Kris; anyhone opposedt o removing has element
[none]
- Kris; how about also remmoving subject relationship table
[approval]
- Kris; I can push this out to dita-users & dita-comments, but don't think it should stay our hands..


12 noon ET close




-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 14 December 2021

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2022-01-03 16:27:39