The issue is only with glossref, which defaults @print to “no”.
There are a number of issues with the bookmap design.
For example, all the specialized topicref types should be a separate domain so that they can be used in other map types (although our DITA 1.3 ability to use elements from structural domains as though they were domains helps there).
There needs to be a wrapper element around the body topicrefs so that there is a consistent frontmatter/body/appendixes/backmatter structure.
Need to be able to have chapters before the first part.
The book-specific metadata needs to be a separate domain and is woefully underspecified (for example, no provision for 13-digit ISBNs, no provision for ISSNs, no provision for forms of license other than copyright, etc.
There are also places where the design doesn’t allow extension where it should although I’d have to remind myself of the details.
Need more features to enable glossary generation—current glossarylist is not sufficient. Probably need a separate glossary topicref type (from the same domain that provides glossref) to provide clearer signal that a subtree of the map is in fact a glossary.
I’m sure there is more…
Well, the most annoying thing IMO is that even if the keys resolve, they won’t show up in output unless you specifically set print=“yes”. I’ve run into this a ton with term/abbreviated-form.
Specifically looking to allow Keydefs in a more natural position in the map versus the first instance were topicref is allowed in the current content model. Are there other things that we have ignored about bookmaps in DITA 1.3?
We have a number of clients that have hit some limitations for keyref and ditavalref in bookmaps. I would like to work on a proposal that would address those limitations in DITA 2.0. Would it be possible to create a project entry in the DITA 2.0 project?
825 Querbes, Suite 200, Montréal, Québec, Canada, H2V 3X1
tel + 1 514 279-4942 / toll free + 1 877 279-4942
mobile + 1 647 462-3620
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php