Sent: Tuesday, June 09, 2009 6:56
To: Eliot Kimber
Cc: dita; Ogden, Jeff
Subject: Re: [dita] referencing a
bookmap from a map
As a level-set, here's what the spec
currently says about format="ditamap":
linked-to resource is a DITA map. It represents a referenced hierarchy at a
position within referencing hierarchy, and a referenced relationship table
included outside the referencing hierarchy
So it does, at least to me, read like an
explicit behavior. I'd agree that this should be a default behavior, rather
than required. But as a default behavior, I think it should preserve the
validity of the referencing map as it aggregates, and not create invalid structures.
Earlier you wrote:
>My initial reaction to this is that it is
unnecessarily restrictive because
>map-to-map relationships are not really conref relationships (if you want
>conref, use conref) but looser composition (of compound map) relationships
>where the relevant constraints and processing implications cannot be known
Actually if you want conref you can't use
conref - not unless we allow <map> to nest arbitrarily. Note that the
description above says to create the referenced hierarchy at the current
position, but any referenced relationship table should be included outside.
That preserves the validity of the map (which doesn't allow reltable inside a
topicref) in a way that isn't possible with conref.
>That is, when processing a map, a processor need not create a literal new
>map, but simply process the referenced map as it exists, with knowledge of
>the referencing context. In that case, the fact that the referenced
>is a bookmap chapter may or may not be relevant and the user may or may not
I agree that when processors aren't treating
the mapref as an aggregator there's no need to generalize. My concern is for
when it is treated like an aggregator, which is at least the default behavior.
If someone creates an override processor, or
a specialized element with overriding processing, they can do what they want.
But by default, I think that a topicref to a bookmap that pulls it into a
non-valid context should generalize (ie treat it like
an unspecialized map) rather than create an aggregate whole that breaks the
constraints of the structural specialization.
Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
Eliot Kimber <firstname.lastname@example.org>
06/09/2009 06:20 PM
<email@example.com>, dita <firstname.lastname@example.org>
Re: [dita] referencing a bookmap from a map
6/9/09 5:00 PM, "Ogden, Jeff" <email@example.com> wrote:
> There are two classes of users here. Authors
> Different authors will feel differently about
being allowed or
> prohibited from shooting themselves in the
foot. And they may feel
> differently still before and after shooting
themselves in the foot.
> Implementers (like me) are looking for some
guidance. Should we keep
> authors from shooting themselves in the foot,
warn them, but let them
> shoot themselves in the foot if they wish, or
just let them shoot
> themselves in the foot without any warning.
And if we let them shoot
> themselves in the foot, should different
implementations always shoot
> the same foot or can some implementations
shoot the left foot while
> others shoot the right, while still others
shoot the head? As an
> implementer, what I want to avoid is having
someone say that after we
> shot them in the right foot that we should
have shot them in the left
> foot because that is what some other
implementation does or what the
> DITA specification calls for.
> To get back to DITA maps, it would seem that
we have some choices, but
> I'm losing track of who is pushing for what:
> 1) Make map to bookmap
illegal, Bruce's original approach, now
> 2) Allow map to bookmap,
where the bookmap context is not
> overridden by the map, my proposal from
earlier today, still on the
> 3) Michael's proposal
that I'm not sure I understand, but which
> would have map references behave more like
conref and so presumably more
> specialized topicrefs would be generalized to
> topicrefs, or pretty much the opposite of
approach #2 (Michael, correct
> me if I got your proposal wrong).
> 4) Eliot's proposal,
which I'm not sure I understand, but which
> seems to be "anything goes" leaving
it up to the implementers (Eliot,
> correct me if I got your proposal wrong). .
Eliot would proposal #2
> allow you to do what you want to do?
I'm saying #2, without bothering to say anything
about "bookmap context"
because that's a processor-specific implementation
detail. Either processors
are *obligated* to treat more-specialized topicrefs
as generalized to the
level of the referencing topicref (Michael's
proposal) or they aren't. If
they aren't, then how they remember what the
unspecialized type of a given
topicref is is an implementation detail.
I'm also suggesting that any implementor, e.g.,
Arbortext, is free to say,
for that implementation, whether a particular case
is or isn't meaningful,
so if Editor said "maprefs from <map>
to <bookmap> aren't sensical *to us*"
I would be fine with that. But if it instead
"this is the sense it does make
to us" I would be fine with that too (from a
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
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: