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] topic-info-types too restrictive ?


Thatâs how DTDs work: any element type defined in the DTD can be the document element.

 

DITAâs rules restrict the document element to <dita>, a topic element, or a map element.

 

Cheers,

 

E.

 

--

Eliot Kimber

http://contrext.com

 

 

 

From: <dita@lists.oasis-open.org> on behalf of Jang Graat <jang@jang.nl>
Date: Thursday, August 9, 2018 at 12:02 PM
To: Robert D Anderson <robander@us.ibm.com>
Cc: Chris Nitchie <chris.nitchie@oberontech.com>, DITA TC <dita@lists.oasis-open.org>
Subject: Re: [dita] topic-info-types too restrictive ?

 

Thanks for the clarification. I did not know that the composite topic can have any topic type as its root. I will check if that is indeed supported in the FM implementation of DITA. Not sure if the original developer(s) thought about this corner case.

 

Jang F.M. Graat
Smart Information Design
Amsterdam, Netherlands
Cell: +31 646 854 996



On 9 Aug 2018, at 17:44, Robert D Anderson <robander@us.ibm.com> wrote:

 

Right.

And while it's probably not at all useful, it would also be legal (purely for illustration) to create your own shell that does not include the <dita> wrapper, where the root element <topic> could only nest <concept>, and <concept> could only nest <reference>, which in turn could not nest anything.

The closest thing we have that already ships with the standard is the <glossgroup> topic type, which is purely a container topic that nests <glossentry> topics (or more groups). That document type is configured so that <glossentry> cannot nest itself or any other topic.

Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification
Marketing Services Center

 


E-mail: robander@us.ibm.com

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA

<19288250.gif>



<graycol.gif>
Chris Nitchie ---08/09/2018 10:37:45 AM---Additionally, you donât have to use the <dita> root element when using the composite doctype. This i

From:  Chris Nitchie <chris.nitchie@oberontech.com>
To:  Robert D Anderson <robander@us.ibm.com>, Jang <jang@jang.nl>
Cc:  DITA TC <dita@lists.oasis-open.org>
Date:  08/09/2018 10:37 AM
Subject:  Re: [dita] topic-info-types too restrictive ?





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

 


E-mail: robander@us.ibm.com

11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA

<19802380.gif>



<19421873.gif>
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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]