RE: [dita] Should Nested Topicrefs Be Allowed for format="ditamap"?

Earlier Eliot Kimber wrote among other things:

> I would be happier with a new construct that was explicitly a map-to-map reference

In DITA 1.2 we'll have a mapref element. It is a convenience specialization of topicref. Does that help?

The DITA 1.1 specification doesn't say anything about the case of a topic referencing topicref nested within a map referencing topicref. I think it would be good if we added something to the DITA 1.2 spec. to clarify what the behavior should be in this case or it could just say that the behavior is implementation dependent and the practice is discouraged. Either approach would be OK with me. I don’t think we should completely prohibit this.

Today when the Arbortext Editor encounters such a construct during composition or when the Check Completeness operation is requested, you get the following warning:

WARNING

The output behavior when content is nested within a

topic reference that references a map is not well defined by the DITA

Standard. Such usage is discouraged since it is not portable and may

change in the future.

The top level topics from the map and the topics included from the topicrefs nested within the map referencing topicref are then all included as peers, not because it is necessarily the right thing to do, but because it seemed better to do something than nothing.

-Jeff

> -----Original Message-----

> From: Eliot Kimber [mailto:ekimber@reallysi.com]

> Sent: Thursday, March 06, 2008 10:05 PM

> To: dita@lists.oasis-open.org

> Subject: [dita] Should Nested Topicrefs Be Allowed for format="ditamap"?

> I'm implementing my own chunk to-content processing and as a side effect

> of that implementing map-to-map refs. It occurred to me that having

> something like this:

> <topicref href=""submap-01.ditamap"" format="ditamap">

> <topicref href=""foo.dita"/>

> </topicref>

> Doesn't make a lot of sense since it's somewhat ambiguous where the

> subordinate topicref would effectively be relative to the contents of

> the target ditamap.

> I think this case should be disallowed but I haven't thought about it

> that deeply.

> This use of topicref has always seemed a little iffy to me. I would be

> happier with a new construct that was explicitly a map-to-map reference

> but I realize it's probably too late to make that design change for 1.2,

> if it would be appropriate to make it at all.

> But I think we should clarify the constraints in this case: either

> disallow the case above or state clearly what the effective result is.

> Cheers,

> Eliot

> --

> Eliot Kimber

> Senior Solutions Architect

> "Bringing Strategy, Content, and Technology Together"

> Main: 610.631.6770

> www.reallysi.com

> www.rsuitecms.com

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail. You may a link to this group and all your TCs in

> OASIS

> at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

dita message