Re: [dita] referencing a bookmap from a map

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

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

The question is what do you want to
happen by default.

By default, currently, a topicref to
another map pulls that map into the processing context. This is not the
only possible result, but it is certainly a possible result. If you do
nothing except create a topicref to another map, and produce output, I
think it is a reasonable default to expect the target map to be pulled
in. It is also perfectly reasonable to override that default.

The question is whether, *by default*,
I should be able to pull in specialized portions of the target map into
contexts *which will break default processing*.

In other words, should the preprocess
step that resolves references across specialized maps allow specialized
content into places where it is not valid?

>In the case where map is only providing navigation
>... 
>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.

You can organize your map any way you want. The question
is, and has been from the start, what to do with the specialized semantics
of the target *when aggregating the content for further processing*. The
fact that other use cases exist is not relevant to this one.

Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

Eliot Kimber <ekimber@reallysi.com>

06/12/2009 04:15 PM

To	"Ogden, Jeff" <jogden@ptc.com>, dita <dita@lists.oasis-open.org>
cc
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>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php