OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]