Additionally, you donât have to use the <dita> root element when using the composite doctype. This is fully legal:
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<concept id="concept">
<title>Concept Title</title>
<task id="task">
<title>Task Title</title>
</task>
</concept>
As a matter of fact, Arbortext remaps all of the base topic types to ditabase to avoid duplicating configuration settings.
Chris
From: <dita@lists.oasis-open.org> on behalf of Robert D Anderson <robander@us.ibm.com>
Date: Thursday, August 9, 2018 at 11:28 AM
To: Jang <jang@jang.nl>
Cc: DITA TC <dita@lists.oasis-open.org>
Subject: Re: [dita] topic-info-types too restrictive ?
Topics (including specialized topics) are allowed to nest any kind of topic. That's generally the reason it's handled with that entity -- so that you can extend it with other types of topics, so long as you only put topic types
in there (putting something else in there would break various specialization rules).
In the OASIS-shipped document types, which many people use as templates, we have topic that nests topic, concept that nests concept, and so on; but in the composite type with root element <dita>, those same entities are set up
so that each topic type can nest any of the included topic types. So when using that one, topic can nest concept, concept can nest reference, etc.
Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification
Marketing Services Center
|
Jang
---08/09/2018 08:07:42 AM---Working on a DITA implementation in FrameMaker I stumble over the restriction that a topic only allo
From: Jang <jang@jang.nl>
To: DITA TC <dita@lists.oasis-open.org>
Date: 08/09/2018 08:07 AM
Subject: [dita] topic-info-types too restrictive ?
Sent by: <dita@lists.oasis-open.org>
Working on a DITA implementation in FrameMaker I stumble over the restriction that a topic only allows topic elements to be nested. I would have expected the topic to allow specialisations of topic (such as concept, task and reference and possibly troubleshooting)
as well in that location. Of course every type of nesting can (and probably should) be done with maps instead of nesting topics, but the standard does allow topic nesting. So if people want to use this, they should be able to use specialised topics as well,
without having to redefine the topic-info-types. Would such a redefinition be legal (assuming I also add the modules for concept, task, reference and troubleshooting to the topic document shell so that all elements are defined) ? Would that count as a specialised
topic ? Are there points I am missing in the original discussions of nesting topic types ?
Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands
Cell: +31 646 854 996