For what it's worth, we tried having an alphabetical list of elements at
the end of the language section, but something tells me it isn't being
noticed by most people. I'm not sure how to improve that. The lists are
available with a couple of groupings, or as one long list:
http://docs.oasis-open.org/dita/v1.2/os/spec/element-quick-reference.html
A couple of ideas - the specification previously came in multiple docs
(architectural specification and language specification). We could have a
companion doc that is part of the specification deliverable, linked to from
the main page (like we link to the DTDs and XSDs), and store the
contains/contained-by items in there (linked to from the main language
spec). That could be done as a single doc, or as individual docs (which
would easily let us include only the learning modules with a future
learning package). If we did that, and if we found a way to simplify the
attribute tables (big if), then the PDF could conceivably become small
enough to print out. I know, a fantasy...
A less advanced idea would be to store the content models in an appendix,
which would at least mean that a search from the front of the PDF would hit
the element descriptions before hitting the content models.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
From: "Jang F.M. Graat" <>
To: DITA TC <>
Date: 09/12/2012 00:58
Subject: Re: [dita] DITA 1.3 documentation -- shall we remove the
Contains and "Contains by" tables
Sent by: <>
Hello all,
I agree with Tony that the problem is the search method, not its
availability. Having an alphabetical list of elements, possibly having more
than one such list - grouped per domain - as hyperlinks in an obvious
location (appendix ? or up front immediately following the TOC) would do a
lot of good for readers of the specs. Full text search is a must if you
want to find that certain phrase you know you have seen before but
forgotten where. Paging through those 1200 pages to find the phrase is
almost impossible to do. Killing the full text search because some people
use it in the wrong way is a bad choice. Removing the tables is a bad
choice, too. Rethinking possible ways of disclosing the information is a
good one.
Ciao
Jang
JANG Communication
Coaching - Copywriting - Consulting
Amsterdam - Netherlands
Tel. +31 20 755 8466
Cell +31 6 5478 1632
http://www.jang.nl
On 12 sep. 2012, at 02:54, Tony Self wrote:
