Groups - DITA TC Meeting Minutes 1 March 2022 uploaded

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

        Submitter's message
        ActionItems:  None


=================================================
Minutes of the OASIS DITA TC
Tuesday, 1 March 2022
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, Gershon Joseph, Eliot Kimber, Zoe Lawson, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Frank Wegmann, Jim Tivy


Business
========

1. Roll call
        Regrets: Dawn Stevens, Carsten Brennecke 


2. Approve minutes from previous business meeting:
        15 February 2022
            https://lists.oasis-open.org/archives/dita/202202/msg00023.html (Harrison, 18 February 2022) 
Kris moved, 2nd Scott, approved by TC


3. Announcements - none


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

  
5. Review K: Metadata and cascading metadata
        Opening of review: https://lists.oasis-open.org/archives/dita/202202/msg00021.html (Eberlein, 15 February 2022)
        Final status: https://lists.oasis-open.org/archives/dita/202203/msg00000.html (Eberlein, 01 March 2022) 
- Kris; all comments have been handled; please look at the leaderboard. any questions?
[none]


6. Metadata questions for the TC to consider
        https://lists.oasis-open.org/archives/dita/202202/msg00030.html (Eberlein, 28 February 2022) 
- Kris; these issues came out of both the DITAWeb review and some comments on dita-users group.
- Robert; First item is about reconciling topic and map metadata conflicts. We had a table in the spec at 1.3 that talked about what cascades. We have the same table attached to the email above, which answers the following questions:
    - When metadata elements are specified on the

element, do they then also apply to submaps? To topics referenced in submaps?
- Does the behaviour differ based on whether a map is a root map or a submap?
- Robert; we can infer some other answers, but it's not really clear. I'm trying to resolve these questions with the latest table. For the third question, we haven't made it explicit as to whether it applies just to the root map, or to root map and also to submaps; the answer is open to interpretation. Also, if it's set on a submap, does it apply to the submaps of that submap?
- Eliot; on the question of submaps, my first inclination is to say that metadata in submaps is ignored if it's set in the root map. We already ignore titles on submaps; if it isn't ignored, it couldn't be overwritten by the root map, which is certainly the way most users expect it to be. In that case, we wouldn't have the ability to override that metadata from the root map. Also, to the degree that a submap is treated as just the accumulation of its topics, you wouldn't want its metadata to override that of the root map. or the topics it includes.
- Robert; your reasoning is just like mine; if your specify an audience on root map, it needs to override any submap values.
- Kris; the metadata set at root map propagates down thru submaps, but I can also see utility of metadata from root map supplementing metadata on submaps, rather than just negating them.
- Robert; yes, but part of my problem is that today's map can be tomorrow's submap.
- Kris; right, category is an example; if you have a user guide with a submap for each category, you'd want metadata specific to each category set in that submap.
- Robert; we have that right now.
- Eliot; there's no single behavior that will satify all use cases.
- Kris; it's inevitable that we can't come up with something that meets all needs.
- Zoe; the major distinction is between whether it's an overwrite or a supplement.
- Eliot; yes, and that goes back to "how do I want it to behave in the instance?" e.g., "what if I don't want to supplement metadata, but just override?"
- Zoe; what about cascading?
- Robert; that doesn't work for these elementa.
- Eliot; my instinct would be to have a simple rule that works for most use cases, and if someone wants something different, they can do some work.
- Kris; so the default behavior is to add/supplement topics, not override?
- Robert; we used to have some where the default was to override, like with shortdesc and navtitle, but we've replaced those.
- Gershon; how does that work if an author can override what's in the topic?
- Robert; looking at 1.3, the only one that did that was searchtitle, which has gone away.
- Eliot; if we say all these are inherently additive, the solution is to not set it at map level if you don;t want it to override lower levels.
- Gershon; so what happens, for instance, if you have an author responsible for bookmap, but pulling in chapters from other parts of a knowledge base, written by other authors?
- Robert; should this be interpreted as 'map and submap'
- Eliot; I'd take it to mean maps and submaps
- Kris; so anything ref'd in root maps cascades infinitely, and any submap data cascades down to any sub-submaps.
- Robert; that's my understanding, but it would be clearer if we change to 'all subamps and ref'd submaps.'
- Kris; and we should also have an example of that to make it clearer.
- Robert; yes
- Eliot; yes, if we're explicit about it, that has important implications for processers; they can't just blindly grab metadata for a map and blindly plug into submap without looking at the metadata in that submap.
- Kris; so are we in agreement; root maps and submaps both cascade.
- Robert; the next major item is about processing cascading @s. For section 2.1.1 (Processing cascading attributes in a map), the answer I came up with is 'yes, that's correct. The way to explain this is to add an example that shows every step of this. I just don't know how to explain it in words so it's more understandable; it's really hard. The basic steps are: first resolve the conrefs, at that point explicit values in doc are evaluated; then, after looking at things in the doc, then use defaults from the grammar files (dtd/rng). One problem is that the processor may not know the difference between what's declared in the document, and what's in the dtd/rng files.
- Kris; say you have a reltable with @toc="yes". does proceessor stop at step 2?
- Robert; yes, if you've set toc="yes" in reltable, that gets used. otherwise, the default from dtd/rng gets used.
- Kris; so the processor may not go thru all the steps, it just goes until it gets an answer...
- Gershon; if you get the @ from a step, then you're done.
- Robert; we explicitly say apps must continue thru this until a value is reached or you get to the end of the list. it's a normative rule.
- Eliot; I'd prefer to express this as a set of precedence rules, rather than a processing algorithm, so we should specify precedence rules.
- Robert; the trouble is that you have to do the processing../
- Eliot; no, you can express it as a pre-condition.
- Robert; first, let's go thru the list, but maybe step 7 and 8 should be reversed.
- Eliot; we might be able to fix that by removing step 6, because step 10 might give you what you want.
- Robert; I think you're right.
- Kris; we currently have it in the spec in algorithm format, and it's someplace else in precedence format. but we know that TC members stumbled over the review, so we want TC members to understand the way it works.
- Eliot; and explaining the algorithm in a non-normative note would be great.
- Kris; or we could do this in a flow chart.
- Eliot; but the twiddle about'processor-supplied defaults is confusing.
- Robert; right, you have to first figure that out.
- Kris; Frank, does this discussion provide clarification?
- Frank; yes, it does. I felt I wouldn't have been able to describe to someone how it happens.
- Zoe; do we explain what controlled values are?
- Kris; those come from a subjectscheme map; it's covered in the subjectscheme material.
- Robert; that's the sub-chapter that comes immediately before this one.

- Robert; the next item is cascading of roles, which is a bit disgusting; this came out of bookmap in 1.1, and if you just ref something with what you pull in, (See draft of 5.3.3.3) If you have a submap, you have to say how role cascades.
Kris; I think we've done the correct thing for bookmap, but not for anyone who creates specialized maps with specialized topicrefs. So maybe we should try to add an @ that says when this applies, i.e. when the topicref you're using refs a submap. so that the semantic meaning cascades down; if your topicref is referencing a topic, this @ doesn't apply; it applies only if a topicref is BOTH specialized AND it references a submap.
- Eliot; this is a case where hard cases make bad law, because of bookmap.
- Robert; No, the whole reason we ran into this was that submaps weren't chapters, they were published as independent articles.
Unfortunately a better solution was encoded at 1.1.
- Zoe; how about @semantic-processing-role?
- Robert; I'd thought of @preserve-role; when you'r using it on a mapref, you want to preserve the values.
- Eliot; maybe @impose-role?
- Kris; if we add an @, it would take yes/no values, right?
- Robert; right.
- Zoe; I'd prefer @defining-role.
- Kris; shall we move forward to clarifying this for 2.0? We could add an @ and set the default value, in the grammar.
- Robert; it would just be a new @ that will clarify behavior
[gen'l approval for adding this]
- Kris; I approve also; it woud be bad to go into 2.0 without fixing it.
[gen'l approval]
- Eliot; the only thing is that it would be nice to say what the semantic role is that's being applied, but we can take that up next time.
- Kris; we'll try to have another review up on Friday, it will be on addressing, but not key-baed addressing, just basic addressing.



12 noon ET close

-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 1 March 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-03-04 22:25:18