Re: [dita] Map structure and possible new attribute for conref pushand anchorref

[Eliot Kimber <ekimber@reallysi.com>]

On 2/3/09 1:41 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote:

> Proposed name:
> "localdisplay". In previous discussions I've suggested  a name of
> "appear" or "display" but "localdisplay" is now my favourite (I think
> Gershon suggested it).

I'm not entirely happy with the name "localdisplay". My main objection is to
the qualification "local" since the meaning of "local" is a bit ambiguous,
although I understand the intended meaning in this context.

In addition, this isn't really about display but about the role the
information plays in the process of determining the final effective
structure of the processed result. And while "display" is probably clear
it's a little too tied to specific processing intent for my taste.

I'm wondering if we don't need to first codify a concept that is inherent in
DITA processing but never really made explicit, namely the distinction
between content that is "primary" and content that is "secondary", where
primary content determines the structure and content of the final effective
result of processing or access and secondary content supplies dependencies
used by the primary content.

For processing or access, primary content is always directly accessible (is
presented directly, has appropriate navigation structures provided for it,
is findable by search, etc.) and secondary content is never directly
accessible (is never presented directly, has no navigation structurs
pointing to it, cannot be found directly by search but only in the context
in which it is used, etc.) but is only presented indirectly through the use
of conref or links (e.g., as created by relationship tables).

By default, all topics referenced explicitly in a map are primary and all
topics not referenced in a map (but linked from topics, at least by conref
links, if not all types of link) are secondary.

Given that distinction, then the attribute could be meaningfully named
"primary-secondary-content" with a default value of "primary" and
"secondary" meaning "these topics do not directly contribute to the
effective result of processing the map". Note that I explicitly didn't call
this attribute "content-type" simply because the term "content-type" already
means "MIME type" or "data type" to most people.

This approach has the advantage that it is completely generic with respect
to the type of processing to be applied or the nature of the processing
result, at the cost of being a bit more abstract. I think it better reflects
the true nature of the distinction that needs to be made.

But I think that making explicit the fact that there are these two classes
of content would make this whole discussion clearer to both users and
implementors, even if we go with Su-Laine's original proposed name and
values.

Cheers,

Eliot

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