Deb Bissantz and I had an action item to talk about this. We think that we want to bring this issue back to the TC and focus more on the basic use case before we leap to the potential solution. (The potential solution that we discussed on 22 August 2018 was moving <schemeref> into the map group domain; currently it is defined in the subjectScheme specialization.) Original use case The original use case that lay behind Deb's e-mail (
https://lists.oasis-open.org/archives/dita/201808/msg00043.html ) was that map authors should have a clear way to reference a subject scheme map in a DITA map or book map. 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. Here's how we reference a subjectScheme in the source for the DITA spec: <frontmatter> <mapref href= type= subjectScheme /> <mapref href= processing-role= resource-only /> <mapref href= format= ditamap /> <mapref href= /> <notices platform= dita-tc-publishing > <topicref href= linking= none toc= no /> <topicref href= linking= none toc= no /> </notices> <notices platform= external-publishing-engine > <topicref href= /> <topicref href= /> </notices> <booklists> <toc/> </booklists> </frontmatter> Using the @type attribute in this way is not something that we cover at all in the current spec ... Do we need to? Potential solutions <eberlein> I can think of a few: Formalize the current use of @type= subjectScheme on <mapref> (Pro: Clarifying what map authors need to do for subjectScheme support) Add a convenience element that defaults the @type attribute so that map authors do not need to remember to set it (Minus: Bloat of convenience elements) Move <schemeref> to the map group domain (Solution that Robert Anderson suggested on 22 August 2019) I have some concerns about #3: I've never understood why we (OASIS DITA TC) integrate the map group domain in to the subjectScheme shell. I've never seen the use for any of the elements there, and I routinely remove the domain from subjectScheme shells. (Sure, I could write a constraint to remove all elements from the domain except <schemeref> and use that for the subjectScheme shell.) I was planning to suggest that we remove the map group domain from the subjectScheme shell for DITA 2.0. Processors, at least the DITA-OT and oXygen, have never implemented much support for <schemeref>. I opened an issue about this in March 2013:
https://github.com/dita-ot/dita-ot/issues/1482 The issue is now closed, but the problems related to <schemeref> were never fixed. I supposed I should get up the energy to open new issues about <schemeref> ... Are there other possible solutions? Thoughts? </eberlein> Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 622-1501; kriseberlein (skype)