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] referencing a bookmap from a map

On 6/9/09 11:06 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> Hi Jeff,
>>   Topicref to bookmap:
>>      Chapters in the bookmap maintain their ?chapterness?
>>      Parts in the bookmap maintain their ?partness?
> If we think of a mapref as being parallel to a conref (basically a
> shorthand for "pull the target hierarchy into this point in this
> hierarchy, but push reltables to the end because they're not allowed
> within a hierarchy") then we should discard the chapterness - just like we
> discard <step>ness when we conref from a <li>.
> Otherwise we allow chapters to nest, and break any bookmap processors that
> are expecting DTD-validated content.

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

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 topicref
is a bookmap chapter may or may not be relevant and the user may or may not

I think part of this discussion may result from an inherent bit of fuzziness
in the design of map-to-map references, which is that there is no necessary
well-defined thing that is the target of the reference to which, for
example, a type check could be applied.

That is, there is no requirement that a referenced map have exactly one root
topicref. In the case where there is no single root topicref, there is
nothing to which a topicref could be unambiguously checked except the map
element itself, but the map element is not reliably distinguishing (consider
the L&T map domain, which allows the inclusion of very specialized topicrefs
into an otherwise unspecialized <map> element).

So I think we are obligated to say that map-to-map references are
unconstrained by the spec and its up to processors to decide what is or
isn't meaningful for a give use instance.

Certainly in my "library map" use case, where I want a map that points to
multiple bookmaps, my intent is clear and I can implement processing that
makes it sensible, and that processing will almost certainly not be to treat
the entire map as a single virtual map instance document but to treat the
library map as a set of navigations to the otherwise individual bookmaps.
There's nothing in the current DITA language that lets me express this
intent directly (unless it's possibly scope="peer" on a map-to-map
reference, but scope="peer" is seriously underspecified in the 1.2 spec as
currently drafted and certainly doesn't address this particular question).

I would be very uncomfortable saying that processors are *obligated* to
treat references to specialized topicrefs as generalized. I would be OK with
saying they *can* treat them as generalized.

I would also be OK with saying that the type= attribute can indicate the
type of the top-level topicrefs a given map-to-map reference effectively
addresses, e.g.:

<topicref href="mybookchaptermap.ditamap" type="chapter"/>

If this form of type= was required in order to preserve the specialized
nature in processing referenced topicrefs, I would be OK with that, since it
doesn't preclude the functionality but does make intent clearer and enables
designers to build in constraints in specializations.



Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> 

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