OASIS Darwin Information Typing Architecture (DITA) TC

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:

Hi, Eliot:


I'd agree that it doesn't make much sense to assert child navigation against a remote map (though it would make sense to assert child navigation against an anchor within a map).


We've had some discussion that navigation is only the default intepretation of a map -- that it really expresses relationships between content -- and I'd think that bears here.  While the default interpretation doesn't make sense, I can imagine associating a map with design-time topics explaining the rationale for reusing the map in the context or guidelines for what goes in the referenced map and what in the context, with relationships to semantic definitions for classifying or filtering the content of the map in reuse, with relationships to properties for processing the map in context, and so on.



Hoping that's useful,



Erik Hennum

ehennum@us.ibm.com



Eliot Kimber <ekimber@reallysi.com> wrote on 03/06/2008 07:04:43 PM:


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

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

 

Ogden, Jeff wrote:


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

No, because it's still really a topicref and since it's only a 
convenience should be reliably replaceable by an unspecialized topicref.

A dedicated map-to-map reference would have a pure map composition 
semantic much more in the vein of conref than the more abstract (and as 
Erik points out, flexible) topicref.

But that train has already left station and won't be back until DITA 2.

I do think the behavior you describe for Arbortext is appropriate.

Cheers,

Eliot
-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com