[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/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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]