OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita-comment] Links to Conditional Content (was Public Comment)


comment-form@oasis-open.org wrote:
> If the boolean expression represented by a set of %select-atts;
> attributes evaluates to false, the relevant element (topic, heading,
> table, etc.) should be hidden by the delivery engine (browser,
> XML-->PDF converter, help viewer, etc.).
> 
> What happens to a link to an element that has been hidden?  In
> specific terms, what happens to an entry in a table of Contents
> [TOC], Index [IX], or Related Topics list that points to a hidden
> element?  What happens to an in-line embedded cross-reference to a
> hidden element?

This is part of a larger fundamental problem in hypertext and re-use: 
how to process links within information sets where particular anchors 
may or may not be present in a given view or rendition of that information.

The problem you've stated is a subcase of the more general problem that 
occurs when you have re-used content--the links in that content may only 
be relevant in a particular use context.

That is, say I have two re-usable topics A and B. If A links to B it 
establishes a dependency relationship from A to B such that the full 
presentation of A depends on the existence of B such that link from A to 
B can be resolved.

The fact that A and B are re-usable implies several things:

- A and B may be used in different contexts (e.g., different, 
independent maps, different publications, etc.

- A and B may not necessarily be used in all the same contexts.

- A and B may be used in multiple contexts, any one of which might be an 
appropriate resolution target, presenting an ambiguity about where to go 
at traversal time, or at least requiring a choice to be made in some way.

This is complicated by the fact that A and B may be published in various 
ways with different linking capabilities: as HTML pages, as PDF 
documents, as print, as something else.

This means that regardless of how the links are authored they will need 
to be transformed into a form that is appropriate for the publishing medium.

For example, in HTML things can be pretty simple: you can have a 
publishing sytem in which each topic is published exactly once as a 
single HTML page. Thus links as authored can be translated directly to 
HTML links without having to worry about use context.

But in PDF, where you are publishing a set of topics as a single PDF 
document, you have to know which *delivery context* your link targets 
should resolve to. For example, say that topic A is used in Publication 
1, which is published as a single PDF amd topic B is used in Publication 
1 and Publication 2. Should the link from A to B resolve to B in 
Publication 1 or B in Publication 2 or to both instances of B? What if B 
is only used in publication 2? In that case, when you publish 
Publication 1 you have to know where topic B will be so you can 
construct the link.

Given this analysis, you can think of conditionality (or applicability 
as I prefer to call it) as just another way in which the use context is 
determined.

That is, a given set of conditions applied to a set of topics represents 
a "view" of that information in exactly the same way that a DITA map 
establishes a view--the conditions simply say more about the view than 
simply what topics are in or out.

It should be clear that these are knotty problems that in practice has 
to be addressed in ways that are most appropriate for the local business 
process, information charateristics, and authoring constraints. There's 
only so much that you can do in the base information representation 
itself to address this problem, apart from enabling sufficient 
flexibility in how your links and addresses are defined and managed.

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122

ekimber@innodata-isogen.com
www.innodata-isogen.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]