This came up about a year ago for one of the customers I support. They ended up with some strange (unexpected) behaviors, though I can't remember what exactly. When I tracked it down to a mapref inside of a reltable, the owner of the content had no idea why it was there, and was happy to remove it. So in all the time I've been supporting DITA users, that's the only time it came up, and it was clearly an error in the source.
My expectation for this reference is the behavior you describe for the toolkit today - it pulls in all of the topicrefs from the map, just as it would do in a TOC. So, you end up with a bunch of topicrefs in one cell. This could be useful for really tiny maps, but I'd be scared to rely on it as a way to manage links. Also, what happens if the map you reference itself has a reltable?
Because we can't actually forbid creating the reference, and it has (almost) never come up, and somebody might perhaps come up with a clever/logical thing to do with it (like your peer map sample), I think I lean towards leaving this unaddressed. I think we'd all agree that at this point we don't want to create any new reltable-specific behaviors for map references in 1.3.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (
http://www.dita-ot.org/ )
Eliot Kimber ---02/12/2015 15:23:00---This came up on the DITA User list today: a user was trying to use a mapref within a relcell to refe
From: Eliot Kimber <
ekimber@contrext.com>
To: dita <
dita@lists.oasis-open.org>
Date: 02/12/2015 15:23
Subject: [dita] Implications, if any, for maprefs in reltablel?
Sent by: <
dita@lists.oasis-open.org>
This came up on the DITA User list today: a user was trying to use a
mapref within a relcell to refer to the current map in order to create
relationships between the current map and some external resources.
In thinking about this and in rereading the reference entry for
relationship tables, it's clear the reltable design was entirely focused
on topic-to-topic relationships. In addition, since reltables predated the
ability to use topicrefs to point to maps, I don't think anyone ever
thought about the implications of a mapref in a relationship table.
The use case from DITA Users did point up that there's no defined way to
say "this map" (meaning this root map) within a relationship table. That
is, there's nothing you could put in a relcell that would mean "I'm
relating the root map containing this relationship table to the things
linked from the other cells of this relrow". I'm not suggesting we try to
fix that in 1.3, just observing that it is the case.
However, I think we need to at least think about whether we need to say
anything about what it means to have a mapref within a relationship table
cell or if that should even be allowed.
For example, I could do this:
<reltable>
<relrow>
<relcell>
<mapref href= >
</relcell>
<relcell>
<topicref keyref="resource-01"/>
</relcell>
</relrow>
</reltable>
My expectation for this would be that the topicrefs in the referenced map
would be treated as though they had occurred directly within the relcell
and that appears to be what the OT does based on my testing just now.
In the case of referencing the current root map, per the current rules,
that fails because you can't have a recursive map reference. Of course, we
could decide that for DITA 1.3 referencing the root map has a special
meaning in reltables, but I'm definitely *not* suggesting we add that,
just observing that it would be a not-unreasonable way to approach the
issue. But since this is the first time I think anyone has mentioned it,
it's not a critical design issue.
For DITA 1.3 we've added a meaning for peer-scope map references. So you
could do this:
<reltable>
<relrow>
<relcell>
<mapref href= scope="peer"
keyscope="pub02"
/>
</relcell>
<relcell>
<topicref keyref="resource-01"/>
</relcell>
</relrow>
</reltable>
In that case, the relationship could only be between the peer publication
and the other ends of the relationship--it wouldn't make sense to relate
all the topics in the peer map. In this case, it would be sensible enough,
for example, to generate a cross reference to the target publication from
the related local topics--there's enough information in the to be able to
do that in the context of a more general cross-deliverable-link-capable
processor.
That case is clearly not explicitly addressed in the current reltable
language reference entries. Should it be? I certainly didn't consider this
case during the development of the cross-deliverable linking proposal.
It's probably OK to continue to say nothing since we've made it this far
and I think the behavior I've just outlined is a pretty reasonable way to
interpret the spec as it currently is.
But I wanted to at make sure that we had at least considered the case of
maprefs within reltables as it's obviously been overlooked for a long time.
Cheers,
E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php