Re: [dita] referencing a bookmap from a map

[Eliot Kimber <ekimber@reallysi.com>]

On 6/12/09 2:25 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> If we feed our existing bookmap processes a combo map - ie we literally
> aggregate several of them together, including multiple backmatters etc. -
> and we normalize and remove DTDs so there's no validation issue - do the
> processes work?

That assumes there is a current bookmap process that works at all :-)
 
> In other words, is there any code in bookmap that depends on the
> structural rules of bookmap being followed? If there are multiple
> definitions of the book title, for example, does the code know to take the
> first one, even though structurally there should only ever be one? If
> there are multiple indices, does the index processing know to look only
> for index entries within each subsumed bookmap, rather than the scope of
> the whole map?
> 
> I understand why the use case below is a nice-to-have - but are we
> prepared to (re)code every process for specialized maps to allow for the
> possibility of aggregation and recursive nesting, even when explicitly
> prevented by the specialization? For example, if we allow <topicref> to
> <appendix> to retain its <appendix>ness no matter where we're referencing
> from, then we are allowing <appendix> inside <frontmatter>. And <chapter>
> inside <appendix>.

Certainly my proposal #4 modifies #2 to explicitly allow any particular
process to say "thank you for playing, but I don't accept this particular
combination of stuff".

That is, I don't see the *ability* to create particular combinations of
things via maps as necessarily obligating processors to support those
combinations--maps are, by their nature more amorphous in their semantics
and constraints because they sit on the boundary between pure content
(topics) and use-case-specific processing and semantics (publishing in the
context of my data and business processes).

The implications of both map specializations and specific combinations of
map constructs is already understood, by necessity, to require more custom
processing then base topic processing. Or at least it should be.

But in any case, if you have a new map that includes some bookmaps, the
input to your processing is *not* a bookmap, it's some other kind of map
that happens to include some bookmaps. Whether that implies normal bookmap
processing of those included bookmaps is, I think, a question left to the
user, not something that can be imposed, or even guided, by the spec.

> And if that is ok, then my question would be - why don't we allow the same
> arbitrary nesting rule in the DTD? If we're going to allow reusers to
> circumvent the content model by reference, why won't we let them do the
> same thing without referencing? Either way we need to add the code to
> support it, so why the limitation for people working in just one document?

Yes, well the bookmap design, in particular, is broken in any number of
ways, the inability to nest chapters possibly being one of them. For this
reason (that bookmap's design is clearly not fully cooked) I think it is
dangerous to use bookmap's particular constraints or lack thereof as
compelling examples.



----
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>