Re: [dita] Limitations of titlealts

[Eliot Kimber <ekimber@contrext.com>]

It's difficult to assess your requirements as stated in this mail without a deeper understanding of the business problems, but the focus on navigation titles seems suspect to me: navigation titles are intended to be used in navigation structures (e.g., ToCs, lists of links) and in that context it's not clear how different delivery or use contexts translate to different navigation titles.

I think it's important to distinguish between the same topic used in different publication contexts (that is, different publications irrespective of how they are delivered) and the same topic published to different delivery contexts.

It may be that in your scenario that there is a one-to-one mapping from publications to delivery types (that is, a given publication is only delivered in exactly one way).

If the same topic is used in different publications and needs different navigation titles in those different use contexts then you can use the topicrefs to impose navigation titles onto them. That is, each publication can impose its own publication-specific navigation titles.

If the same topic is used in a single publication but delivered to different delivery contexts and needs different title or navigation title texts in those different delivery contexts I'd first ask "why?" Why do different delivery contexts for the same publication require different navigation titles? But if the need for delivery-specific text is justified then the requirement can be met by using subelements within the navigation title element with @deliveryTarget (or any other conditional attribute) to select the appropriate value. Not necessarily ideal markup for authoring, but the mechanism is there today and wouldn't result in significantly more markup than having multiple navtitle or searchtitle elements. 

If you wanted to provide specialized markup then you could define your own navtitle specialization that then allows specialized <text> or <ph> elements for the different alternatives.

One concern with allowing multiple instances of a given title alternative is that you then need rules for what to do when multiple instances are effective for a given delivery instance. 

That is, if your intent is to allow multiple navtitle elements and then have all but one filtered out for a given deliverable, what happens when the filtering doesn't happen? Which one do you choose? Not a show stopper, but the rules need to be thought out and documented and then implemented in processors and authors have to then be trained on the implications of not setting up filtering correctly.

Cheers,

Eliot
--
Eliot Kimber
http://contrext.com
 

ïOn 8/28/18, 9:53 AM, "Bill Burns" <dita@lists.oasis-open.org on behalf of bburns@healthwise.org> wrote:

    Hello,
    
    We're running into some problems with the limitations of the titlealts model. We have about 9 different channels to which we publish and have different needs for titling
    
    We are using navtitle for a number of purposes, but we're finding that one navtitle or one searchtitle isn't cutting it. For example, we have a product called a patient instruction, which is very flat. We use navtitle for clinical titles. However, if we decided to use that map as part of a knowledge base article (which is a much longer piece), we'd need the navtitle to generate the navstack, and we'd want that not to be what a clinical sees but what a consumer would see. In addition, we have Content-as-a-Service, which has a whole different set of requirements for titles, as the service presents content at the topic level. Ideally, we'd be able to specialize navtitle for these purposes, but because of the restriction of one navtitle or one search title, we're no better off.
    
    I'd like to propose that we add a general purpose alternative title that can occur more than once and can be used as a basis for specialization would allow us to create proper semantics for our various title type, and we'd be less likely to just shove our titles into navtitle or search title.
    
    Thoughts?
    
    Bill Burns
    Content Architect | Healthwise
    bburns@healthwise.org<mailto:bburns@healthwise.org> | www.healthwise.org<http://www.healthwise.org/>
    208.331.6917 (office)  |  208.345.1897 (fax)
    
    Healthwise helps people make better health decisions.
    
    
    ---------------------------------------------------------------------
    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