[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
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" <bob.thomas@tagsmiths.com> 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 (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]