[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 Eberline, Chris Nichie, Zoë Lawson
2. Appove minutes
Posted by Nancy on the 24th. Kris moves to approve.
Bill burns seconds.
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
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 Eberline - 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.
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 Eberline: Deb Bizance proposed for stage 1
Discussed 8/22 - potentially move schemeref to map group domain.
After discussiong 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 Eberline: Yes
Scott Hudson: agrees. Not a lot of overhead to add.
Kris Eberline: Robert?
Robert Anderson: Not much more to add. Sounds reasonable.
Kris Eberline: 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 Eberline: If remove schemeref out of subject scheme and move into mapgroup, that may effect 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 Eberline: sorta kinda
Robert Anderson: Is this part of technical debt?
Kris Eberline: 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 Eberline: 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 Eberline: 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 Eberline: has caused trouble in the spec.
Elliot Kimber: Key scopes is the solution. Peer scope would solve this.
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 Eberline: Subject scheme uses keys in many ways. Subject scheme values; classification map values (often forgotten)
Robert Anderson: I agree
Kris Eberline: doubley 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 Eberline: 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 Eberline: there is a classification domain. Part of 1.2; integrated into any map; 100% relies on keys. Forget all the elemetns - 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 Relations hisp tables to idenify 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 Eberline: 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 Eberline: 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 Eberline: 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 pearman - 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 Eberline: Glad you brought that up. If really doing a rework of subject scheme. Remove classification maps and subject defintions.
Elliot Kimber: Yes. Not taht design is bad...but how likely are people giong to do it in DITA.
Kris Eberline: 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/indevelopment. 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.
<sound apologies Kris Eberline on mute>
Robert Anderson: Started with easy way to reference a schemeref from map - new element
Should we tease apart subjectscheme - into constraints and classification
Should we drop classification
Kris Eberline: 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 contorlled values vs. taxonomy subject. Seems straight forward...but don't have enough background to say yay or nay.
Kris Eberline: 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 nameing 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 Eberline: Just to try and wrap this up today.
could do more detailed look into deeper look into subject scheme. Kris would be willign 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 Eberline: 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.