Attendance for TC meeting on 21 December 2022

Meeting Minutes 21 December 2021

1. Roll call: [Kris, can you please supply? I didn't know I was taking minutes

at the time.]

2. Unable to approve minutes from previous business meeting (14 December 2021)

as they haven't been recieved yet.

3. Announcements

None

4. Action items

- 16 November 2021: Gershon: Talk to Precision Content dev team about developing

tool to generate contains/contains content

Gershon: Haven't really moved on; end of year hampering efforts.

- 07 December 2021: Eliot: Develop new example for object element-reference

topic

Eliot Kimber: Started looking at this, didn't find a way for launching a PDF

that uses Param that works.

The params usually go into the URL, so still thinking.

5. Review E: Table elements

Kris Eberlein: Review of comments, most have been closed, but 8 need to be

discussed.

(Review what's in the email:

https://lists.oasis-open.org/archives/dita/202112/msg00041.html.)

Robert Anderson: about the comments that need to be discussed come down to icky

CALS stuff.

CALS was a table model that could handle anything and everything.

OASIS Exchange model is slightly simplified.

DITA <table> came from that.

There are some attributes that aren't really used, so what should we do about

it?

E.g. in the review there were several "I've never heard of this attribute..."

that zero in on things that maybe we want to consider removing.

Reading the OASIS spec doesn't help. A) you need to read ANOTHER spec and B) it

doesn't really explain it well anyway.

Should we drop some bits? But what's the risk. Just because I've never used

them, doesn't mean others don't.

Most tools already support CALS via shared modules, so is it worth fixing it?

Not quite sure what to do.

Kris Eberlein: We haven't had a great chance to discuss these comments, so

forgive us for potential disagreements.

Robert Anderson: Apologies, life and holiday, we don't have suggested solutions.

Gershon: Because we're referencing another OASIS standard, why drop stuff?

What does the OASIS Exchange Set say about their model? Is there an issue about

using a subset.

Kris Eberlein: Good thought, but let's pause to see if we decide to trim

anything before we get to this.

There are a few orient, rotate about "hey your local processing may override",

dropping those statements

trying to alphabetize attributes

Tidying up examples that were wrong.

What do we want to cover in examples? Do we cover everything? e.g. the display

attributes in CALS tables. Do we need to state that local stylesheets may or may

not override display attributes.

What do we want to cover with <desc>?

Tone of examples?

Based on comments, will add topics to architectural portion of spec on

accessibility. E.g. adding headers in tables

Robert Anderson: Yes. In tables there's a lot of specific stuff for

accessibility, how do they interact, etc. There are implied things, but we

should be explicit.

These questions have highlighted that we need an accessibility section in the

spec.

Will be great to say "yes, look here, see how accessible we are!" and have one

place to point to.

Kris Eberlein: Adding screen captures for examples for table and simpletable.

Please review and give us feedback.

Accessibility - we can explain more in <alt>

It's a clearer representation.

Just using DITA source...it might look like this...maybe. Harder to understand

without an image.

ZoÃ Lawson: thank you. spanning hard.

Kris Eberlein: Robert Anderson and I are reviewing and making guidelines where

images might be useful.

Robert Anderson: If we just use samples...when folks republish the the spec...

with things missing or garbage, etc. So that the rendering of the spec no longer

changes examples.

Kris Eberlein: Even if that means we taKris Eberlein more time writing alt text,

it's good.

Questions/comments?

Kris Eberlein: Please, review the comment PDF and the rev marked PDF

to better understand what all we're talking about and how we got here.

FYI, screenshots of tables are done via a Word mock up, so easy to fix.

6. Questions to TC from review E

* What do we want to state about rendering <desc> when it applies to tables?

https://lists.oasis-open.org/archives/dita/202112/msg00036.html (Eberlein,

20 December 2021)

Kris Eberlein: This was sparked by Gershon. Do we want to mention that <desc> is

read by screen readers...but the spec says <desc> SHOULD be rendered in text...

so is that obvious in the table description.

Do we need a rendering expectation section in <desc>.

ZoÃ Lawson: I say yes becasue of how I use spec. Generally only looking at the

element reference.

Kris Eberlein: Other thoughts?

Robert Anderson: the other question in here, but what if <desc> is used just for

screen readers? It was a legacy thing from IBM because the content was displayed

at IBM.

As long as you are consistent with your content, either is fine...but you have

to be consistent.

Saying SHOULD leaves the wiggle room. Is that enough.

Kris Eberlein: Hesitant about adding rendering might use this, and can screw up

interoperability between different existing use cases.

Robert Anderson: Fine with leaving it out.

Kris Eberlein: Spec editor suggestion: put rendering expectation, should be

rendered into <table> processing expectations.

Do not mention could be just for screen readers.

Eliot Kimber: looking at HTML table, <alt> says "use <caption>", so we're

following what the HTML spec does.

Scott Hudson: What about the table summary that is used by screen readers.

Different from caption.

Robert Anderson: Yup, that was the question.

Eliot Kimber: The details of DITA to HTML is implementation.

Scott Hudson: Thought there was a statement that we enable that.

Kris Eberlein: "that"?

Scott Hudson: We provide technology that provides ARIA markup, but we don't map

it specifically.

....

Kris Eberlein: We don't actually make that statement, and we don't map DITA to

ARIA. We just say "you should render <desc>"

Eliot Kimber: Going by spec for HTML5, there's <summary>, and it says use

<caption>. In DITA, table/title = caption, and so that doesn't work.

Robert Anderson: that's what the DITA-OT does.

Huh. <summary> has been deprecated. didn't know that.

Since that's true, don't add mapping.

[info from Scott H: https://www.w3.org/WAI/tutorials/tables/caption-summary/ ]

Kris Eberlein: Yup. Not gonna do that.

We will add rendering expectations to <table> about <desc>.

No mention of <desc> in table summary meta data.

* Tone for examples in the DITA spec

https://lists.oasis-open.org/archives/dita/202112/msg00037.html (Eberlein,

20 December 2021)

Kris Eberlein: Comment from Dawn, the tone is all over the place.

What do we want?

Only have "not only relate to software and hardware"

Realistic if possible.

At least one example, but do not need to show everything.

Very interested in thoughts from TC. Dawn?

Dawn Stevens: Nothing really to add. Do we come up with a generic product that

all examples would be based on? but that wouldn't work because need a mix of

source (software/hardware/etc.)

So, don't have a better idea right now...

Robert Anderson: like the idea for a User Guide for DITA, but other verticals

get cranky, so we need to be broad.

Dawn Stevens: Yup, see that point. But, tech writing says "avoid humor" so maybe

we should avoid things that are goofy.

ZoÃ Lawson: Like the humor, but understand.

Frank Wegmann: In a User Guide, you can have a "single" over arching example.

But for the spec, really need to show different things expecially showing what

you really need to see in an example.

Kris Eberlein: Expect that we won't standardize the Tone in 2.0 time frame.

Especially since things are being updated as we go.

The particular example we were discussing was completely replaced because there

were issues.

All simpletable examples are now food related, but that's not too terrible.

Robert Anderson: Should hat tip to Jarno and have vegan food...

Kris: Probably can't really resolve...but keep it in mind. Just, be rich in the

example.

Just...keep stewing on this. We'll add guidelines as we go.

7. Status of review D

Kris Eberlein: Skipping. Havne't been able to work on it. If you haven't participated, please get comments in by EOW.

On hold until spec editors have reviewed existing comments and discussed

8. What does it mean to mix DITA 1.3 and DITA 2.0

Robert Anderson: every presentation, Can I mix?

"Check with your tools, but probably, maybe..."

However, as other questions are coming up. Roger, who does DITA-OT doc, was

trying to mix, and using chunking.

Oh. Implementation is totally different. So maybe it shouldn't mix.

(Yes, DITA-OT is starting to early adopt early versions of DITA 2.0.)

Mixing maps is a bad idea.

Don't think we the TC want to write an expectations guide. Trying to explain

"what happens when you reference one type of topic from another map and vice

versa, etc." is just way too much work.

And we don't have the resources.

And not our place.

We're supposed to define 2.0. We don't ever say you need to support both.

and contrary, we shouldn't tell processors that they shouldn't try to support

both.

Kris Eberlein: There are responses from Gershon, Frank and Kris.

[https://lists.oasis-open.org/archives/dita/202112/msg00039.html

(Anderson, 21 December 2021)

https://lists.oasis-open.org/archives/dita/202112/msg00040.html

(Joseph, 21 December 2021)

https://lists.oasis-open.org/archives/dita/202112/msg00042.html

(Wegmann, 21 December 2021)

https://lists.oasis-open.org/archives/dita/202112/msg00043.html

(Eberlein, 21 December 2021)

]

Gershon: We should not be promoting concurrent use.

When you upgrade, you have to upgrade all the things.

Wouldn't expect to use 1.3 and 2.0 at the same time...and if they do, you're on

your own.

Compatibility guide is a crazy idea.

Dita 2.0 is backwards-incompatable, and we should keep it that way.

Should state from the TC, you should migrate everything. But okay if the TC

doesn't want to say anything.

Robert Anderson: I partially agree and partially don't.

"If you mix, you're on your own" is a perfectly valid statement. And the right

message.

The migration will take time. There's going to be legacy stuff. You should be

able to figure out...something. But not our problem.

Frank Wegmann: That's the right perspective. Don't give users the opportunity to

mix.

Probably not part of the spec to include, but in a migration guide, yes.

Or, tool vendor can do whatever.

Otherwise, migrate.

Eliot Kimber: Agree with Robert Anderson that the TC shouldn't have an opinion.

Not our business to decide what a processor can do.

Should be clear what "backward-incompatable" really means. Markup yes, but

structural no.

DITA 2.0 is still DITA, you just need to tidy up migration things.

A processor or a CMS needs to figure out solutions, but not our problem.

Kris Eberlein: Highlight there are two issues.

1. Will implementation and tooling supprot 1.3 and 2.0 content, if segregated.

Expect tool to handle that, does not want to make a statement that precludes

that.

2. What happens in processing when things mix via map.

Robert Anderson: For folks with lots of content, probably forced by what the

CCMS does.

More of a question for folks not in prescriptive tools.

E.g. if you're all DITA-OT, what will the DITA-OT do.

YMMV is the best response.

Kris Eberlein: Or, our CCMS support one version of DITA at a time. You pick when

you start.

Robert Anderson: If you can't support 1.2 and 1.3, definitely not going to do

1.3 and 2.0

Kris Eberlein: wonder what tool vendors are starting to do... No response from

webinars.

12 noon ET close

[No review this week. No meeting next week. Happy Holidays.

Next Meeting 4 January 2022]

dita message