Re: [dita] referencing a bookmap from a map

[Michael Priestley <mpriestl@ca.ibm.com>]

Eliot Kimber <ekimber@reallysi.com> wrote on
06/16/2009 10:36:33 AM:

> We are clearly not communicating.

I agree. We need a phone call.
> 
> My point is that the spec does not specify rendition processing for
maps
> (not even for bookmap). Nor should it.

http://docs.oasis-open.org/dita/v1.1/OS/langspec/langref/indexlist.html

> I repeat: the only two questions are:
> 
> 1. Is generalization *required*?
> 2. Are processors free to reject maps that provide combinations of
> ungeneralized topicrefs that make no sense to that processor?
> 
> I think the answer to (1) is "no" and the answer to (2)
is "yes".

I would like to have a general description of how
aggregation works in particular. One of the goals of the 1.2 spec was to
more clearly define these behaviors. It is not limited to bookmap, but
bookmap provides some good illustrations.

Also, I've said several times now that it's not generalization,
and I was wrong to call it that. The rule I'm proposing is that the semantic
of the referencing element should win over the semantic of the referenced
element - even when the referencing element is more general.

> If there is a desire to make the constraints
on bookmaps, in particular,
> clearer, then the definition of bookmap needs to be extended beyond
it's
> current very brief definition.  But that is a separate issue.

I think the constraints on bookmap are actually quite
clear, from a processing perspective. It has a DTD and a schema, which
are the industry-standard ways to express those constraints. The question
is whether - post-aggregation - we should expect those same constraints
to still apply, or whether aggregation by definition is going to be open
to breakage. In other words, will aggregation of maps be able to cope with
new specializations, or will aggregation of maps always require special
coding for each new map doctype? (Or be at risk for causing unanticipated
breakage)?

> I have already observed that the bookmap elements are significantly
> underspecified if the intent is for people to understand what, for
example,
> "chapter" means and why it would be inappropriate to not
nest them.

Thus moving what is currently a DTD constraint into
a human-readable guideline? Or we could set up processing by default to
not create DTD-invalid aggregations.

Michael Priestley