OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]