Re: [dita] Troubles with the info-types implementation pattern and with topic nesting in troubleshooting.dtd

Thanks all. I didn't know about <no-topic-nesting>. Sorry for the noise about *-info-types.

Unfortunately, I still have the bug with troubleshooting.dtd to address. I will put that in a new thread, because my suggested fix in this thread is no longer what I want.

Best Regards,

Bob

On Wed, Apr 1, 2015 at 11:42 AM, Eliot Kimber <> wrote:
Bob,

This is why the <no-topic-nesting> element exists: to allow this parameter

entity to exist and always have a DTD-valid value.

Cheers,

E.

—————

Eliot Kimber, Owner

Contrext, LLC

http://contrext.com

On 4/1/15, 12:31 PM, "Bob Thomas" <> wrote:

>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 () or Skype

>Time zone: Mountain (GMT-7)

>

>

>

>

>

>

>

>

-- 

Bob Thomas
+1 720 201 8260

Skype: bob.thomas.colorado

Instant messaging: Gmail chat () or Skype

Time zone: Mountain (GMT-7)