RE: Technical content specializations to add to proposal #647

[kris eberleinconsulting.com <kris@eberleinconsulting.com>]

Part of what I want to do with the proposal is to open the door to folks building processing â especially processing likely to be interchangeable â around this attribute. And also open the door to adding processing expectations for @subjectrefs in DITA 2.1.

 

The DITA-OT (and other processors) never built processing support for the classification domain because of at least the following factors, I think:

• Poor design of the domain
• Inadequate documentation of the domain and processing expectations for it in the spec
• The fact that it would be almost impossible to build generic processing for the domain

 

In an ideal world, we would have hashed through this proposal during the formal DITA 2.0 proposal process, and it would have included processing expectations. But we didnât.

 

My gut instinct is to keep the current proposal as simple as possible, both because of the late time frame, but also to make it likely that:

• Processors and implementations can build processing support.
• The DITA can add processing expectations in a future release.

 

To me, that seems a good reason to only add @subjectrefs to topicref specializations that would be clearly used to reference topics that need classification â

 

The more discussion on this the better, I think.

 

Kris

 

 

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> On Behalf Of Eliot Kimber
Sent: Monday, March 28, 2022 9:46 AM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Re: Technical content specializations to add to proposal #647

 

I would generally prefer to allow it everywhere and let users ignore it where itâs not relevant. If pressed I can imagine a credible use case for classifying anything a topicref might point to 😊

 

Itâs hard to see a harm in allowing @subjsectref on all topicrefs since it has no required processing associated with it.

 

Cheers,

 

E.

 

_____________________________________________

Eliot Kimber

Sr Staff Content Engineer

O: 512 554 9368

M: 512 554 9368

servicenow.com

LinkedIn | Twitter | YouTube | Facebook

 

From: dita@lists.oasis-open.org <dita@lists.oasis-open.org> on behalf of kris eberleinconsulting.com <kris@eberleinconsulting.com>
Date: Monday, March 28, 2022 at 7:53 AM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Technical content specializations to add to proposal #647

[External Email]

 

There are a lot of specializations of <topicref> in the technical content edition! Here are my thoughts of what to include (and what to exclude):

Elements to include:
Elements that typically reference topics that might be about a wide variety of subjects:

• <appendix>
• <chapter>
• <glossref>
• <part>

I was a little on the fence about enabling @subjectrefs on <glossref>, since glossary topics are tightly focused topics about a single term. But then I thought of a few (credible?) use cases for it:

• Enabling folks to generate output based on a subjectScheme map (an explanation of subjects for the authoring team, perhaps) that would also include related terms
• If an implementation was using subject classification for some sort of faceted browsing experience, perhaps they would want to be able to surface related terminology

Elements to exclude:

• All the list elements in bookmap
• All the bookmap elements that are narrowly focused and have specific sematic meaning, <colophon> and <dedication, for example
• All the bookmap elements that serve as a grouping element, <frontmatter> and <backmatter>, for example

Thoughts? Let me know if you object, preferably before I send an updated proposal to the list.

Best,

Kris