I agree with
all the referencing-related improvements and also second the
proposal to change how the bookmap metadata is structured.
The deliverable metadata should not be limited only to
bookmaps, is too limiting in its current structure, and
doesn’t conform to any other standards (see other posts
about the options for this).
As for the
glossary generation, many of my clients struggle with
presenting term/definition/alternative form (usually
acronyms). The elements are available in the glossary
topics, but there is no easy way to structure or specify
the generated list type in the deliverable map.
Thanks for
starting this discussion.
Have a great
day,
Amber
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…
Cheers,
E.
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?
Éric Sirois
DITA Toolsmith
IXIASOFT
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
eric.sirois@ixiasoft.com/www.ixiasoft.com
Hi,
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?
Kind regards,
Éric Sirois
DITA Toolsmith
IXIASOFT
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
eric.sirois@ixiasoft.com/www.ixiasoft.com
---------------------------------------------------------------------
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