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: Public Comment


Comment from: hedley.finger@myob.com

Following up my previous post (posted by Michael Priestly as "Re: otherprops"), the technical committee should consider the general problem of links to conditioned topics (also known in the trade apparently as "topic maps", e.g. DITA bookmap).

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?

I believe that such entries should inherit the conditional attributes of their targets.  But this raises another problem.

What is the relationship of condition attributes in a parent containing element to conditions attributes in a child contained element?  Imagine the case where a parent has a set of conditions that evaluate to false (hidden) but a child element has conditions that evaluate to true.  I would like to think that the truth values of the parent conditions and the child conditions AND.  In the example, all content and elements in the parent, whose conditions evaluate to false, would be hidden, including the child with true conditions.

I think that the DITA specifications and usage recommendations should explicitly state that the truth values of parents and children are always ANDed to allow consistent specialization.

Back to the problem of references to elements.  If a reference (entry in TOC, IX, Xref, RelTopics) inherits the condition attributes of its target element, the visibility of that element may be determined by the visibility of a parent container.  So a browser or other app will have to reverse traverse the element tree to determine the visibility of the current target element of a reference.  How far up the tree should the browser traverse?  What if the element is in an reused fragment embedded in a topic (i.e. file entity, included file, or whatever) -- how does the browser determine which is the host of a fragment which could have been embedded in many different topics/files?

I don't know how far the committee can address this problem in the specification but believe the general problem should be recognized somewhere in any documentation addressed primarily to implementers.

Keywords: condition profile link target cross-reference xref hyperlink href bookmap bookinfo


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