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/12/09 1:50 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> One use case that uses map to specialized map references involves
> several separate "books" each developed independently and each with
> their own map.  Each map is a different map specialization. As an
> example we might use a bookmap and a learningbookmap.
> 
>  
> 
> At a later time someone wants to create a new deliverable that includes
> two or more of these existing "books".  So they use a generic map that
> references each of the specialized maps that they want to include,
> something like this:
> 
>  
> 
> map
> 
> title
> 
> topicref to bookmap
> 
> topicref to leaningbookmap
> 
>  
> 
> They might well get two separate frontmatter and backmatter sections,
> one for each book and that is fine.

But in fact this use assumes that the intended (or only allowed) result is a
single unit of publication.

But in fact, as indicated in my note of a few minutes ago about clarifying
peer, there is no DITA-defined notion of "publication" nor is there a way to
indicate that a given map is only navigation over separate publications as
opposed to defining an atomic unit of publication.

In the case where map is only providing navigation, it's hard to argue that
nesting reference to one bookmap inside a reference to another bookmap would
be a problem since it's a purely navigation relationship and may simply
indicate a hierarchy (similar to the library navigation trees we had at the
front of the manuals in the Networking System publications back in my day).

That argument alone, is sufficient, I think, to make it clear that
disallowing any particular organization of stuff in a map by the spec would
be wrong--the sensibleness is entirely a function of the processing
semantics of the map and not the things included.

Cheers,

E.

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