dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Troubles with the info-types implementation pattern and with topic nesting in troubleshooting.dtd
- From: "Robert D Anderson" <robander@us.ibm.com>
- To: Bob Thomas <bob.thomas@tagsmiths.com>
- Date: Wed, 1 Apr 2015 11:46:13 -0600
Hi Bob,
This is a known issue that came up in the original DITA 1.0 design, and is the sole reason for the (otherwise useless) element <no-topic-nesting>. If you want to turn off any nesting of topics, you need to use that element in the info-types parameter entity (or task-info-types or whatever specific topic type you are using).
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)
Bob Thomas ---04/01/2015 12:31:55---Assuming that the spec allows DTDs to be configured so that nested topics won't be present, I have f
From: Bob Thomas <bob.thomas@tagsmiths.com>
To: dita <dita@lists.oasis-open.org>
Date: 04/01/2015 12:31
Subject: [dita] Troubles with the info-types implementation pattern and with topic nesting in troubleshooting.dtd
Sent by: <dita@lists.oasis-open.org>
Assuming that the spec allows DTDs to be configured so that nested topics won't be present, I have found a design flaw in the DTD implementation pattern for *-info-types. Consider this example from topic.mod:
<!ENTITY % topic.content
"((%title;),
(%titlealts;)?,
(%shortdesc; |
%abstract;)?,
(%prolog;)?,
(%body;)?,
(%related-links;)?,
(%topic-info-types;)*)"
>
The problem with this construct is that it will not allow %topic-info-types; to be set to empty. The presences of the comma, the parenthesis, and the * occurrence-operator mean that a valid element name must be furnished by the %topic-info-types; parameter entity or the DTD will fail to parse. To correct this, the definition for %topic-info-types; must include the comma, the parenthesis, and the occurrence operator. For example:
<!ENTITY % topic.content
"((%title;),
(%titlealts;)?,
(%shortdesc; |
%abstract;)?,
(%prolog;)?,
(%body;)?,
(%related-links;)?
%topic-info-types;)"
>
The parameter entity definition in topic.mod becomes necessarily ugly:
<!ENTITY % topic-info-types
", (%info-types;)*"
>
As also does the one in topic.dtd:
<!ENTITY % topic-info-types
", (topic)*"
>
This flaw has existed throughout DITA 1.2 and lives on in DITA 1.3. It also suggests that few, if any, have tried to turn off topic nesting.
I discovered this while researching George Bina's question about the "topic" element being available at the end an embedded task topic in a troubleshooting topic. That flaw was caused by the fact that I had neglected to override the the task-info-types parameter entity in troubleshooting.dtd. Specifically, the following parameter entity needs to be added to the TOPIC NESTING OVERRIDE section in troubleshooting.dtd:
<!ENTITY % task-info-types
"task"
>
Without that override, task.mod defaults the task-info-types value to %info-types; allowing topic to appear as nested topic at the end of task. Of course, my preference would be to set task-info-types to empty in troubleshooting.dtd. And, that's how I discovered that the DTDs won't parse with empty *-info-types.
At any rate, the fix for troubleshooting.dtd and the *-info-types problem need to go on the TC agenda soon.
Best Regards,
--
Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]