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

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.


> 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

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