Corrected Meeting Minutes for October 29, 2019

Meeting Minutes for DITA TC for October 29, 2019

by Zoë Lawson and Bill Burns.

Attendance: Bill Burns; Robert Anderson, Stan Doherty, Eric Sirois, Elliot Kimber, Scott Hudson, Carlos Evia, Kris Eberlein, Chris Nichie, Zoë Lawson

2. Approve minutes

Posted by Nancy on the 24th. Kris moves to approve.

Bill burns seconds.

Approved

3. 22 October 2019

From the To-Do list: Kris: Communicate with dita-users moderators about TC support for moving to Groups.io is COMPLETED

Elliot - needs to follow up on nag emails

Item 6:

Stage 3 vote #21 - Resolve inconsistent class values for shortdesc, linktext, and searchtitle

Kris E.: Posted updated PDF with correct affiliation

Elliot K proposes we approve Issue #21

Robert Anderson seconds

Zoë Lawson - yes

Kris Eberlein - yes

Bill Burns - yes

Robert Anderson - yes

Stan Doherty - yes

Elliot Kimber - yes

Eric Sirois - yes

Chris Nichie - yes

Scott Hudson - yes

Carlos Evia - yes

Unanimous, will move on to adding to spec etc.

Item #7

DITA 2.0 proposal: #163 Element for referencing subject scheme map

(Note from Zoë: Some of this conversation got very technical and occasionally I lost the thread. There may be some gaps.)

Kris Eberlein: Deb Bissantz proposed for stage 1

Discussed 8/22 - potentially move schemeref to map group domain.

After discussion with Deb, wanted to bring back to group.

Currently, all we say in the spec about how to reference subject scheme maps in DITA maps or book maps is the following (added for 1.3):

"A DITA map can reference a subject scheme map by using a <mapref> element. Processors also MAY provide parameters by which subject scheme maps are referenced."

(2.2.3 Subject scheme maps and their usage)

Realistically, in order to get DITA-OT or oXygen support for such map references, folks have to add a @type attribute."

Not covered in current spec. Do we need to?

Elliot Kimber: Type attribute shouldn't be required; but then processor knows it doesn't need to resolve. So it would be useful.

Elliot Kimber: @type helps processors avoid having to process things they don't need.

Kris Eberlein: Yes

Scott Hudson: Agrees. Not a lot of overhead to add.

Kris Eberlein: Robert?

Robert Anderson: Not much more to add. Sounds reasonable.

Kris Eberlein: Adding schemref to mapgroup may be opening up a can of worms. Do you need any other parts of mapgroup with subject schemes.

Also no editors use schemeref right now.

Robert Anderson: May have misunderstood question. May create issues with subject scheme itself.

Kris Eberlein: If remove schemeref out of subject scheme and move into mapgroup, that may affect a lot of existing implementations. (Folks trim mapgroup out of schemeref.)

Robert Anderson: Skeptical of scheme ref since not many support it. Let's move something out of a place we don't want to move it because no one's implemented it.

Kris Eberlein: Sorta kinda

Robert Anderson: Is this part of technical debt?

Kris Eberlein: Didn't think of this as technical debt. Kris opens most of the issues...but didn't follow up on certain things. We should ask for processors to have better support for schemeref.

And should have clear references to different types of maps.

Does moving schemref into mapgroup actually really help (with subjectscheme)

Robert Anderson: Are we changing the purpose of subject scheme?

Kris Eberlein: You're backing away of adding schemeref to mapgroup domain.

Robert Anderson: Maybe?

Moving schemeref to mapgroup made sense until Kris outlined places where it doesn't work.

Chris Nichie: Issue that naming of the element and the thing and they type are all the same which is confusing.

Robert Anderson: Agree. Call it SubjectSchemeRef

Elliot Kimber: If I reference a subject scheme, may not want key space used in publication. if it's a configuration file, not a key source.. Have it as a peer map, not a local scope map.

Kris Eberlein: that sounds like making a lot of changes

Chris Nichie: If I had energy would change subject scheme to not use keys, but don't have energy

Elliot Kimber: [paraphrase] Subject scheme

Kris Eberlein: has caused trouble in the spec.

Elliot Kimber: Key scopes is the solution. Peer scope would solve this.

Kris Eberlein:

Robert Anderson: Agree with Chris Nichie and Elliot Kimber, want to change it, but don't have energy to come up with a better solution. It uses keys in a way that no other part of dita uses keys; unexpected problems. Key collisions.

Kris Eberlein: Subject scheme uses keys in many ways. Subject scheme values; classification map values (often forgotten)

Robert Anderson: I agree

Kris Eberlein: Doubly convoluted.

Chris Nichie: Is it as simple as adding base subject scheme to hold the value name.

Scott Hudson: Not as attribute value. Not translate.

Chris Nichie: Not translate today. Navtitle used to translate display name.

Used keys because it existed. Would a different attribute name work?

Robert Anderson: Maybe?

Elliot Kimber: If added a new attribute for defining a value, fallback to keys.

Robert Anderson: 2.0 don't go down the route of keepign depricated/bad behavior.

Chris Nichie: Migrate - rename the attribute, or just copy the attribute.

Kris Eberlein: I get uncomfortable when discussing redesigning of subject scheme map. Not sure everyone has dived in deeply enough. controlled values AND taxinomical values.

My usage of this at IBM before 1.2; classification came out of an early prototype 2005-2007 with Mark Henna before 1.2 keys.

Elliot Kimber: Please explain classification.

Kris Eberlein: There is a classification domain. Part of 1.2; integrated into any map; 100% relies on keys. Forget all the elements - specializations of topicref and relationship tables - use those to reference keys in subject scheme.

Robert Anderson: The most basic part is <subjectref> inside of <topicref> this is categorized with thing in subject scheme.

Elliot Kimber: Use Relationship tables to identify subject values

Robert Anderson: [beautiful simplified explanation I lost]

Elliot Kimber: topicref is classified by child subjectref

...

Robert Anderson: If added a new attribute, just rename and copy. But this doesn't quite work because subject scheme does TWO things, sometimes at the same time, so it's not just a simple thing.

Kris Eberlein: Very overloaded

Robert Anderson: Chris Nichie is suggesting really separating the two purposes. If keys, use as key. If control, use new attribute.

Not willing to say if it will work or not, but has value to explore.

Elliot Kimber: I agree.

Kris Eberlein: We've gone down the path of redesigning subject scheme. Which isn't what the original question is.

Elliot Kimber: Main concern of using new attribute without keys. Using keys today, rules for keys precedence may need to apply to control process, which is a lot. if change @key to @controlvalue, that would change behavior based on precedence, whit his a big thing.

Chris Nichie: It is a big thing. But the current process with keys is bad and broken. We should fix it. However, non-trivial, so may not be possible to be fixed due to resource constraints.

Elliot Kimber: Agree. Possible to solve use key precedence if using keys.

Kris Eberlein: Very few people are using subject scheme for classification. Mainly not supported in DITA-OT. Zoomin and (something) are the only people using it. Maybe Easy DITA. For the most part, not a lot of overlap between controlled values and taxonomy, other than audience and platform.

If we had a map for controlled values and a map for taxonomies, for 2.0

Elliot Kimber: that's a complete redesign.

Collides with discussion with Joe Pairman - metadata and classification which is closer to web practices (outside the domain of DITA practices)

Should we use DITA markup for classification since there are so many other tools/technologies out there that people use anyway.

Kris Eberlein: Glad you brought that up. If really doing a rework of subject scheme. Remove classification maps and subject defintions.

Elliot Kimber: Yes. Not that design is bad...but how likely are people going to do it in DITA.

Kris Eberlein: as an end user at IBM using Classification domain...there was a revolt. A lot of overhead; cluttered up maps; hard for maps to see what was going on. Additional layers of taxonomy were hard.

Robert Anderson: Tool support was horrible; keys were new/in development. Very complicated design. Very klunky. Not intuitive.

If starting now, wouldn't use this.

There are people using it...

Can I get my classification information into my HTML...but how/what do you want...but no details.

But if Zoomin is doing something useful.

Chris Nichie: <META> in HTML Head

Elliot Kimber: RDF or JSON that reflect classification that depends on web delivery. But *shudder*

Robert Anderson: that's what IBM did 10 years ago, made RDF.

Elliot Kimber: But web folks don't really want to learn DITA.

Robert Anderson: Started with easy way to reference a schemeref from map - new element

Should we tease apart subjectscheme in to constraints and classification

Should we drop classification?

Kris Eberlein: in an ideal world, would redesign subject scheme for 2.0. May not have the resources for it.

Need to take a deeper look at subject scheme and classification domain. What can we do?

Robert Anderson: Specialized attribute for the type of controlled values vs. taxonomy subject. Seems straight forward...but don't have enough background to say yay or nay.

Kris Eberlein: don't quite know how it would work.

Robert Anderson: Can't come up with an example on the fly.

Elliot Kimber: If understanding Chris Nichie, add a new attribute for the controlled value instead of @key. On the face, seems a simple refinement of current design.

Robert Anderson: keys=product woudl become controlledvalue=product which woudl avoid a bunch of key scope issue.

Elliot Kimber: Change keyref

Chris Nichie: There's some funky stuff in subjectscheme process that treats keyref kinda like conref but relies on key processing, so it might break. There would need to be things fixed.

Elliot Kimber: You'd still use keys [somehow]. The difference would be now could use keyscopes w/o danger of having controlled values changing. Keyscope names wouldn't apply to controlled values.

Chris Nichie: [Some example with product and keys vs attribute name]

Elliot Kimber: Or use some naming convention like productscheme.[something]

Looking at classification domain elements

<subjectref> - as defined above.

All the other elemetns are specializations of relationship tables.

Robert Anderson: Yes. Complicated use of relationship tables.

Elliot Kimber: Makes sense if you like RDF, but would be very surprised if anyone actually did it.

Imposing metadata with external links. (Which is what RDF is, or one of it's main use cases)

Kris Eberlein: Just to try and wrap this up today.

Could do more detailed look into deeper look into subject scheme. Kris would be willing to own a chunk of, but couldn't do alone.

Elliot Kimber: The classification domain in particular - move it off into Github. We don't maintain it as part of DITA spec.

Kris Eberlein: Absolutely. Have suggested it before. May want to remove the classification domain from 2.0.

This needs to live in Limbo.

In conjunction with new metadata attributes.

Following minutes from Bill Burns

Protype migration document—minutes 10/29/19

Zoe Lawson began an outline for a migration document so the TC has something to discuss. It’s basic, not even really a first draft—just a structure to start fleshing out.

It begins with sections for changes in DITA 2.0, an explanation on how to use the document (defines audience and who needs to do what), and a primer on planning a migration.

The rest of the document is broken into four major sections

- Migrating specializations and constraints

- Migrating source

- Migrating transforms

- Items for processors would have to be modified to handle

These will detail what must be done, what should be done, and what might be nice to do. Should include how to update the base and the tech comm domain.

Eliot: said outline looks like a pretty good start but wondered if migrating specializations and constraints should include shells. All shells will have to change at least a little bit.

He would prefer to revise to “shells, constraints, and specializations” because that’s the order in which people will have them. Everyone should have shells. Many will have constraints. Some will have specializations.

Eliot would expect migrating DITA source to precede migrating shells, constraints, and specializations—that’s from an author’s point of view. Practitioners would have to start with the shells.

Kris noted that many won’t have to touch shells, constraints, and specializations at all. We need to consider how the DITA community will be affected.

Zoe asked if the document should be organized by who has the most work or by the number of people affected.

Eliot thinks we should give precedence to the number of people affected.

dita message