Groups - DITA TC Meeting Minutes 11 Januaryr 2022 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItems:  None



y=================================================
Minutes of the OASIS DITA TC
Tuesday, 11 January 2022
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, Gershon Joseph, Zoe Lawson, Keith Schengili-Roberts, Frank Wegmann


Business
========

1. Roll call
        Regrets: Soctt Hudson, Dawn Stevens, Eliot Kimber 


2. Approve minutes from previous business meeting:
        04 January 2022
            https://lists.oasis-open.org/archives/dita/202201/msg00008.html (Harrison, 09 January 2022) 
Kris moved, 2nd Frank, approved by TC 


3. Announcements
        none


4. Action items
[updates only; see agenda for complete list]
    14 December 2021
       Frank, Kris, Robert: Consider usage of the many ways that we refer in the spec to something being determined by an implementation IN PROGRESS 
    21 December:
       Kris: Add statement to table topic that the content of desc is rendered in the flow of text COMPLETED 
    04 January 2022:
       Kris: E-mail dita-users, dita-comment, and Zoomin about the fact that the TC is considering removing classification domain COMPLETED 


5. Status of review F: Attributes used on table elements
        Opening of review: https://lists.oasis-open.org/archives/dita/202201/msg00000.html (Eberlein, 03 January 2022)
        Final status: https://lists.oasis-open.org/archives/dita/202201/msg00011.html (Eberlein, 11 January 2022) 
- Kris; all comments but one have been handled.


6. Review G: Metadata elements
        https://lists.oasis-open.org/archives/dita/202201/msg00016.html (Eberlein, 11 January 2022) 
- Kris; opening today, will run til 1/17; it's small, about 11 PDF pages; note that we don't have natural language descriptions for some eleents, so if you can suggenst them, please do so.
- Robert; for metadata natural language descriptions, I just asked for something besides 'data about data'. I also put in my thoughts about a couple of them.
- Kris; initially I had more reservations about natural language descriptioins, but it does force us to be a little more careful about the topics. trying to write natural language has made me rethink some of the element names we use; it will be useful in future, in designing new elements, to have to use natural language..
- Robert; yes.
- Kris; this review doesn't include the topic for resource-id, which needs more editing before it can be reviewed, and needs to be reviewed in conjunction with architecture topics. Any feedback on last review?
[none]


7. Wondering about specentry / spectitle attributes
        https://lists.oasis-open.org/archives/dita/202201/msg00009.html (Anderson, 10 January 2022)
            https://lists.oasis-open.org/archives/dita/202201/msg00010.html (Joseph, 11 January 2022)
            https://lists.oasis-open.org/archives/dita/202201/msg00012.html (Kimber, 11 January 2022) 
- Robert; these @s have bugged me since DITA 1.0, but one goal for anyone making specialized DTDs, but who doesn't want to customize processing.  Also, it only works for single language docs when you're already customizing DTDs, because the title is hard-coded into processing. If you want to do such a thing, you can do that with specialized @s. so it's time to clean up these @s.
- Gershon; it's a really bad way to handle this, so I support proposal.  It's definitely not a best practice.
- Kris; really flies against what we did in 1.2.
- Robert; practically, it can only function as a token, not a translatable string, unless you abuse the element, which most people who use it do.
- Kris; every instance I've seen was abuse; I might suggest adding an example in content about specialization of how to handle a title for specialized lines or pre. 
- Robert; that's awkward because those elements don't even allow titles.
- Kris; so this is always a hack around that.
- Gershon; we'll need something in migration guide.
- Kris; we have to include something, and can give recommendations about how to get around it. 
- Robert; but we definitely want nothing in the spec.
- Kris; maybe not give advice about how to hack around it.... 
- Kris; we'll need a roll call vote, will go in bug fix list

Robert moved to remove these @s from all elements, 2nd Gershon, 
Voting results:
yes		8 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein,  Nancy Harrison, Gershon Joseph, Keith Schengili-Roberts, Frank Wegmann)
no		0



8. Removing the has elements from DITA 2.0
        https://lists.oasis-open.org/archives/dita/202112/msg00018.html (Eberlein, 09 December 2021)
            New: Feedback from Glen Emerson on dita-users list
                https://lists.oasis-open.org/archives/dita/202112/msg00035.html (Forwarded by Eberlein, 16 December 2021) 
            Eberlein posted on dita-users and dita-comment on 04 January 2022; no feedback. 
- Kris; any objections to moving forward with this? not much used, and it clutters up SS maps, plus there's no expert on TC to maintain it.
[no objections]

Kris moved to remove it, 2nd Gershon
Voting results:
yes		8 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein,  Nancy Harrison, Gershon Joseph, Keith Schengili-Roberts, Frank Wegmann)
no		0


9. Removing

, , and @anchorref
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)
Eberlein posted on dita-users and dita-comment on 04 January 2022; no feedback.
- Kris; have I missed anything this change would affect?
- Robert; no.

Gershon moved to remove these, 2nd Frank
Voting results:
yes 8 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Keith Schengili-Roberts, Frank Wegmann)
no 0


10. Considerations for removing classification map and classification domain
https://lists.oasis-open.org/archives/dita/202112/msg00019.html (Eberlein, 09 December 2021)
https://lists.oasis-open.org/archives/dita/202112/msg00021.html (Joseph 13 Decemver 2021)
https://lists.oasis-open.org/archives/dita/202112/msg00022.html (Doherty, 13 December 2021)
Note: At least two companies, Elucian and Kaplan, are using this
NEW: Proposal for what to do with the classification domain
https://lists.oasis-open.org/archives/dita/202201/msg00017.html (Eberlein, 11 January 2022)
https://lists.oasis-open.org/archives/dita/202201/msg00018.html (Anderson, 11 January 2022)
- Kris; I formally posted to email list what I think we should do with classification map and domain, (see her mail from this morning). The @subjectref would provide keyrefs related to the subjectscheme map. questions?
- Robert; I think it makes sense not to specify processing expectations; we don't have them for the domain today, and it could get complex to add them to this, so I think it should be out of scope, but for someone who wants to associate a subject with their topicref, they could do it.
- Kris; this calls for a stage 1 proposal; shall we move ahead with this?
- Zoe; I don't really understand classification maps...
- Kris; they're a way to associate topicrefs with subjects in a subjectscheme map; they provided needed functionality, but were impossible to use, and it's difficult to do uniform processing based on classification domain, so having a single @ might make processing more possible.
- Robert; creation of these elements was influenced by running as a beta at IBM, so they had to be done as a specialization to base.

Kris moved to remove these as part of a stage proposal, 2nd by Zoe, no objections, approved by TC.
Kris; who will review this proposal?
[reviewers? Gershon, Carsten]


11. Removing the subject relationship table from DITA 2.0
https://lists.oasis-open.org/archives/dita/202201/msg00019.html (Eberlein, 11 January 2022)
- Kris; we talked about this in large discussions, but no formal proposal; I propose we remove this table; I think it offers important functionality, but the design is badly flawed - it should be same as reltable - so the design is complex and hard to follow. We don't have time to re-design it, but we could redo it in a future release if we remove it now. It defines relationships between different subject categories.
- Gershon; I think that's a good approach, I'm not sure we'll redesign it in future, but let's us do this now; remove but don't put it in github repo.

Kris moved to remove subject relationship table, 2nd Gershon,
Voting results:
yes 9 (Robert Anderson, Carsten Brennecke, Stan Doherty, Kris Eberlein, Nancy Harrison, Gershon Joseph, Zoe Lawson, Keith Schengili-Roberts, Frank Wegmann)
no 0


12. (Continuing) Spec terminology: Implementation-dependent / implementation-defined
https://lists.oasis-open.org/archives/dita/202112/msg00004.html (Wegmann, 04 December 2021)
Implementation-specific, implementation-dependent, etc.
https://lists.oasis-open.org/archives/dita/202201/msg00006.html (Eberlein, 04 January 2022
- Gershon; went thru the table you sent out, think don't know how much we can do in 2.0 timeframe, need to define some definitions, b/c we can't use w3c, so idenify terms to use, define them, go thru spec, try to identify them during review, not sure we can fully implement this, but we want to get stated.
- Kris; any points to bring up? on your going thru, did you find anything that wasn't covered by my mail about what we're looking for.
- Gershon; didn't see anything that jumped out at me, i.e., another different use case, can go back and look at it with that in mind.
- Kris; this will be a very iteritive process. may be able to come up with std wording foor various situations/conditions. Frank, did you have any chance to look at this?
- Frank; not this past week, didn't have time. glad we've triggered this process.
- Kris; could move ahead with groupings of element ref topics that we've reviewed so far and see if we can stdize markup there, with markup that could be easily chnaged if we want to tweak it. comments?
[none]


13. 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)
[On hold until spec editors have reviewed existing comments and discussed]


14. Review tooling
https://lists.oasis-open.org/archives/dita/202111/msg00006.html (Eberlein, 02 November 2021)
https://lists.oasis-open.org/archives/dita/202111/msg00016.html (Hudson, forwarded by Eberlein on 09 November 2021)
[no updates]


15. Spec's alternative purpose (continued)
https://lists.oasis-open.org/archives/dita/202111/msg00041.html (Lawson, 22 November 2021)
https://lists.oasis-open.org/archives/dita/202111/msg00044.html (Eberlein, 23 November 2021)
- Zoe; I'm always looking at spec when I need to figure something else; get that we're generic b/c we have to be, but 'this could be used for ...' I feel it coud help with adoption, and would add extra value, but don't know what other peole have bookmarded
- Keith; agree with Zoe. interesting to see how often spec language is cpied into other locations. not enough context in some cases to understand how things would be implementsed
- Kris; we walk a fine line; spec is a legal document; primary audience is folks who will be implementing a DITA processor, secondary audience is authors and IAs, but have to be careful about adding content for 2ndary audience would blur the line for the primary audience. good shortdescs and examples are to support 2ndary aud., but can't lean in direction of having spec lean in direction of w3c tutorials.
- Keith; but at ixiasoft, have been asked by developers about something in spec ; what does this mean?;
- Kris; Robert and I have always tried to use as clear language as possible. DITA 1.0 spec was written as a user guide, and set us on path of imprecise terminology, and left us with stuff we couldn't change; in 1.2, we went overboard in the other direction and tried to sound like legal terminology, which ended up sounding legal but wasn't clear or useful. In 1.3, we tried to return to being precise everywhere while striving to make it usable to evryone.
- Keith; often the 'how' of how to use elements is missing, things are mentioned in HTML specs that are not mentioned here, that would add clarity.
- Kris; just a reminder, we have really run into problems with DITA tables , which are based on OASIS table model; our docs are much more usable that theirs...
- Zoe; when I search for something, I'll usually end up at the element language referene topic; but there's a lot of good info existing that will be in architecture topics. I'm concerned that language ref topics are not linking back to architecture stuff, so you can't find relevant info. For example, learning about ditavals and funky nesting you can do, there's lots of info in architecture topics, but finding that info takes a lot of effort...
- Kris; clearly, we need to have more discussion on this.


12 noon ET close

-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 11 Januaryr 2022

---

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-11 15:01:19