dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 13 December 2022 uploaded
- From: Nancy Harrison<nharrison@infobridge-solutions.com>
- To: <dita@lists.oasis-open.org>
- Date: Wed, 14 Dec 2022 18:28:44 +0000 (UTC)
Submitter's message
ActionItems:
1. Eliot will look at changing the language around how reltables are handled.
=================================================
Minutes of the OASIS DITA TC
Tuesday, 13 December 2022
Recorded by Hancy Harrison
link to agenda for this meeting:
https://wiki.OASIS-open.org/dita/PreviousAgendas
Attendance:
===========
Robert Anderson, Tammy Crowley, Stan Doherty, Kris Eberlein, Nancy Harrison, Scott Hudson, Eliot Kimber, Keith Schengili-Roberts, Dawn Stevens, Kathryn Torriano, Frank Wegmann, Todd Thorner
Business
========
1. Roll call
Regrets: Kendall Shaw, Eric Sirois
2. Approve minutes from previous business meeting:
15 November 2022
https://lists.oasis-open.org/archives/dita/202212/msg00011.html (Harrison, 12 December 2022)
https://lists.oasis-open.org/archives/dita/202212/msg00013.html (Eberlein, 13 December 2022)
[updates needed, will approve next week]
3. Announcements
End of year schedule: We will not meet on 27 December 2022 or 03 January 2023.
Meetings for 2023 have been scheduled
4. Action items and volunteer tasks
08 November 2022:
Kris: Sketch out organization of "Changes from DITA 1.3 to DITA 2.0" topics for base spec
- Kris; I will try to have that sketched out by next week; it's really kind of a high-level marketing topic.
Eliot: Review and rework "Processing cascading attributes" topic
- Eliot; I'll do my best to have it ready for next week's call.
- Kris; and thanks for updating your pull request.
15 November 2022:
Eliot: Update pull request for work related to proposal COMPLETED
29 November 2022
Tammy and Kathryn: Collect orientation information useful for new TC members
- Tammy; we met briefly last week, and we've started gathering info, so it's in process.
- Kris; I will put link for this on TC wiki page; if anyone on TC has info, please add to wiki page, and then Kathryn and Tammy can massage it.
06 December 2022:
Kris: Respond to John Kirkilis on dita-comment COMPLETED
Spec reviews:
Dawn: Examples for general task and
Dawn: Examples for reference (architectural topic) and
- Dawn; no updates yet.
5. Review of DITA 2.0 proposal deadlines
https://wiki.oasis-open.org/dita/DeadlinesDITA2.0
Stage three
(Anderson) New impose-role attribute (https://github.com/oasis-tcs/dita/issues/670)
[on agenda for today]
- Kris; it would be great if we can get this set for a vote next week, that would mean we will have finished all the 2.0 proposals in 2022...
6. DITA 2.0 stage two/three combined proposals
Vote
None
Continuing discussion
None
Initial discussion
@mpose-role attribute
https://lists.oasis-open.org/archives/dita/202212/msg00004.html (Anderson, 06 December 2022)
- Kris; Robert, if you could give the background, Tammy and Kathryn weren't on the TC when this was originally discussed.
- Robert; here's an example of why this was added. When a map specializations, e.g. mapref and chapter, references a map, the grammar has no way to say whether what's being referenced becomes a particular thing; you might be passing along the role, or you might not. Before 2.0, we didn't have a way to specify this. We want to have a way, so that if a chapter references a map, that new map is brought in as a chapter, but if a mapref references a map, that map is not brought in as a mapref. So we've defined a new @impose-role. Default will be to pass on its role. Most techcontent stuff imposes its role, but for most base elements, role isn't imposed.
- Robert; thx to Frank for close review.
- Eliot; as proposal is written, we might need to clarify difference between resource-only and regular topicrefs. It looks like it applies to both, but probably it only applies to regular topicrefs.
- Robert; you're probably correct, but I'm not sure it matters.
- Kris; seems that proessing-role values woould take care of that, so I don't think we need to make the distinction.
[discussion among Eliot, Kris, and Robert; upshot was to leave the proposal as is, and not add any further explanations, since Eliot's proposal was only relevant to rare edge cases.
- Eliot; should role propagate down thru topicgroups?
- Robert; not sure.
- Kris; I think we want to treat topicgroup like any other topicref.
- Robert; I prefer to keep it simple;
- Eliot; and you could have your processor do the right thing for topicgroups.
- Kris; any more on this?
[no more comments]
- Kris; next, do we need to cover any of these edge cases in example topics? Or as examples in new content from Robert? Do we have to dofine w/edge cases
- Robert; if we add special case behavior, then we'd need the example, but if we don't, then it's a question of whether we change the rule for these elements. But the rule is clearly stated, so better not to have examples of edge cases.
- Kris; any other comments questions?
[none, vote next week]
7. dita-comment: ditavalref> should be allowed in
https://lists.oasis-open.org/archives/dita-comment/202211/msg00000.html (Stefan Eike, 09 November 2022)
https://lists.oasis-open.org/archives/dita/202212/msg00008.html (Eberlein, 07 December 2022)
- Kris; this was a comment about why we don't allow ditavalref
in mapref. It repeated an question on the comment list, so I just sent him a reference to the earlier question and answer. And Robert did a very thorough answer - see the link to his answer in my email above.
- Robert; Basically, we could make it happen, but it would have unintended side effects that we don't think woud be useful.
8. Scoped keys and relationship tables
https://lists.oasis-open.org/archives/dita/202205/msg00012.html (Kimber, 22 May 2022)
https://lists.oasis-open.org/archives/dita/202212/msg00007.html (Eberlein, 07 December 2022)
https://lists.oasis-open.org/archives/dita/202212/msg00010.html (Eberlein, 12 December 2022)
- Kris; Eliot, I responded to your comment on the list.
- Eliot; I started to add, to add to example to make it more robust; in example, there are two submaps, which both reference topic1; submap1 has its own version of that topic, diff from topic1 referenced by root map. There's also the question of unqualified keyrefs; you should be resolving to scope-specific uses of topics, which might be different for submap1 from root map, since root map has scope-qualified refs. So if you pull reltables up, you need to resolve the keyrefs. It's not sufficient to just get to a topic, have to get to right use of the topic.
- Kris; the real problem is in the way we've used the concept of 'pulling reltables up;' if we just stop saying that, and use a better description, the question shouldn't occur. The concept came from 1.2, when we thought that intermediate processing had to create valid DITA, but it isn't true, only final resolved links are relevant.
- Eliot; I'm in complete agreement; a reltable only related things to each other; how it gets expressed in a deliverable is all that's matters.
- Kris; and we shouldnt do special things for reltables that we don't do for ordinary links. Any comments or feedback?
- Robert; I agree, we can't talk about equivalences in this context. If the way we talk about things just breaks processing, we just have to change the language.
- Eliot; I'll take and action item to change the language.
***ActionItem: Eliot will look at changing the language around how reltables are handled.
- Kris; this addresses an area that we know was really lacking; ditamap usage topic doesn't really discuss it; it's kind of a dumping ground. We've never really talked about reltables in topics. I think all of this cluster of topics need to be re-authored; it would be very helpful if everyone looked at those topics and see if they're grabbing all info we need to cover, and if you have ideas, suggest a way to organize this info. We're thinking of creating a new topic 5.1, which would be a new topic cluster to discuss architectural issues. What are all the critical things that maps do that were implicit in the 1.x specs, but really need to be explicit? We want to make them explicit and cover them in one place; it's one of the biggest remaining items for 2.0.
- Eliot; I'm looking at the source, where would I find this topic?
- Kris; I urge anyone else in this area to look at this material; this is what I planned to start working on over the holidays.
9. Need for help with DITA 2.0 spec editing
https://lists.oasis-open.org/archives/dita/202211/msg00044.html (Eberlein, 29 November 2022)
Topic clusters where we want help:
https://lists.oasis-open.org/archives/dita/202212/msg00015.html (Eberlein, 13 December 2022)
[Tammy, Kathryn, and Keith all volunteered to help with bookmap, glossary, and release mgmt.]
- Robert; we haven't had our meeting with volunteers yet. Tammy, do you think that would be helpful? although working over holiday isn't likely to happen...
- Kris; I don't think folks need to work over holidays. we have content that we'll open reviews for thru January, so earliest that we'll open reviews of any of this content is mid-Feb.
- Kris; there is a caveat about glossary content; there's probably content in here that needs to be extracted and put into an architectural topic about how we expect processors to deal with abbreviated forms.
- Robert; abbreviated form material is complex and was just shoved in there.
- Keith; none of our business units are using glossary, but they plan to, so my company will want me to do a deep dive on this. There are lots of terms, and lots of acronyms, so there's a real need for this.
- Kris; Robert and I can work closely with you on this; what should stay in the element refs, and what should be taken out... Is there anyone who would be willing to take on mathML, svg, or equation domains?
[Nancy volunteered]
- Kris; anyone for syntax diagram?'
[Frank volunteered]
- Kris; what about xNAL? Stan?
- Stan; I don't know xNAL, but I'd be willing to look at it.
- Kris; it's just in bookmap, and it's ugly.
- Robert; background on xNAL is that we needed to have somewhat more complex name/address/etc. info for bookmap than our core metadata. Some folks recommended we use xNAL; at that point we didn't have concept of foreign element, the way we later incorporated SVG. So we had to take the xNAL elements directly into a domain.
- Stan; is the task to edit it or remove it?
- Kris; task is to bring it up to language quality for 2.0; time is past to either remove it or to rework it; so just light editing to bring it to 2.0 guidelines.
Other:
- Kris; for next week, we'll vote on @impose-role proposal,and do an orienttion on editing the spec.
12 noon ET close
-- Ms. Nancy Harrison
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]