Short version:
* For .ditamap files, .ebook files and/or assembly files,
would it be possible for XMLmind to transclude (or
behave as if it it transcluded) the topics that these
files are referencing?
* For example, in the case of DITA: Would it be possible
to “live transclude” the content that a <topicref>
element references?
Long version:
All the topic based, compound document formats that XMLmind supports
(Docbook, DITA, Ebook) takes the approach of a master document with
links to various external documents to be included when converting
the
master document to the final output.
What is “bad” with this approach - at least as it is implemented
(in
XMLmind - I have not tested other editors) - is that there is very
little one can do from within the master document. One cannot search
inside the content of the embedded documents - for instance. And one
can
neither view nor edit the content of the embedded documents in the
current Tab. To edit, search or view the content, one must first
double
click on a <topicref>, a <chapter> etc in order to open that document
in
another tab. (Currently, in the mentioned master files - .ebooks,
.ditac, assembly.xml - when it comes to searching from within
XMLmind,
it isn’t even possible to search for the the titles or file names
of the
files that the topic references points to.)
For me, the result is that I spend considerable amount of time
checking
the document in a output format - typically XHTML.
In a way, if we think about how topic based authoring is supposed to
work, this can be said to be a little bit ironic. Take for instance
DITA: Each <topic> is meant to be independent. However, in order to
check/verify that a particular topic does not “step on the toes”
of
another topic (for instance, in order to verify that “function
foo” is
only defined inside “topic-foo.dita” and not, as well, more or
less
defined in another topic as too), it would be logical to perform a
seach
for “foo” and see whether one breaks the idea of DITA by, whole
or
halfway, explained it under any other topic as well. However, this is
currently not possible unless I convert the master document to for
example a single-page XHTML document and check within that document.
Wheras when content it transcluded, embedding is still prevented.
However one gets to both see and search the transcluded content from
within the referencing document. Thus, if referred document of
<topicref>, <chapter> etc had been transcluded, it would permit
authors
to view and search the entire document from within the
masterdocument.
(It would only be a matter of enabling or disabling transclusion.)
Workarounds:
For DITA, there is a “hack” that (perhaps) gives you this
functionality
already today, though on the expense of breaking a with the spirit of
best practice DITA:
1. Create a regular map (map or bookmap) and
add e.g. <chapter href="multitopic.dita"/>
2. Then create a single multi-topic .dita file for keeping all
the topics.
3. In the <topicref>, link multi-topic.dita to the ditamap file.
4. Then, create separate single-topic files for each topic.
5. Using @confref, link each single-topic to the multi-topic file,
like
so:
* <topic conref="foo.dita#foo" id="samefil-3">
This arrangement gives (or so I thought) the author the possibility
to
see and search the content of all the conref linked documents from
within the multi-topic files. In such an arrangement, the document
structure becomes governed by the multi-topic file. At the same time,
such an arrangement adhers to the “spirit of DITA”, namely the
idea of
topic per file.
* NB: One problem with this hack, though: The conref included
document,
although visible in XMLmind, did not get included when converting to
PDF
or XHTML. I do not know if this is just another gap in my knowledge
or a
bug in XMLmind.
Btw: This “hack” is also possibe for XHTML documents, by way of
using
<xinclude> (and that is in fact how I used to do it before starting
with
DITA - except that I then had to deal with some other drawbacks -
such
as the fact that XMLmind does not have a tool for creating Table of
Contents for such xinclude-enhanced XHTML files and the fact that
XHTML,
by itself, does not have a standard footnote function - and so on).
