• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 136 subscribers
  • Views 667 views
  • Users 0 members are here
Options
Related

Strategies for reducing the number of output formats

Kendall Shaw

A recurring need is to create outputs from DITA-OT transtypes. The transtypes have parameters specifying any manner of thing, like whether or not to include task labels. Because there is no parameter option for output formats, and because you can't add the same output format more than once, there is an explosion of output formats to handle each combination of parameters, e.g. (for the output output format):

Output to staging with task labels

Output to staging without task labels

Output to qa with task labels

Output to qa without task labels

Output to prod with task labels

Output to prod without task labels

So, 6 outputs for one transtype, because of 2 parameters, when the number of outputs and their parameters continues to increase.

I thought maybe adding a "parameters" metadata item could solve this, but because you can't have more than one of the same output format as an output, this doesn't work.

So, there is an ever growing list of output formats.


How do you handle this?
emoji
Rate translation
×
Suggest better translation
×
Parents
  • 0

    Hi Kendall,

    Good question, and I would love to read some other best practices that people came up with over time. So sharing some thoughts...

    The essence of OutputFormats is to hide the technical complexity and implementation details. For example the "Red Cover Letter-size PDF"; how the PDF is generated and which version of DITA-OT, stylesheets, resolutions required or anything else does not matter for most of the end users.

    Combining an OutputFormat with content like language(s), baselines, resources, etc - it becomes a PublicationOutput. My content in the required language in the "Red Cover Letter-size PDF" layout.

    That PublicationOutput is the most readable/simple entry for many end users on what it is about. You mention of which there can only be one, however I've seen customers that add parameters on the PublicationOutput (so publication language level) that changes the purpose/layout/target of the OutputFormat. In that sense the OutputFormat name is no longer the simple summary so things like with/without labels or TOC - the end user has to look at the metadata if this was published with labels or not. Typically there examples with or without metadata boxes or with or without draft-comments.

    Indeed, if you want all 6 to be controlled, then you need 6 PublicationOutput entries. If you can live with OutputFormat "Output to staging" with a metadata flag on PublicationOutput to tune the publish on what to do, you end up with 3.

    For other forum members I would like to add

    • A half hour somewhat technical introduction on publishing is on TXS 2020 Day 2: Integrating New Publishing Outputs SDL Tridion Docs - YouTube https://www.youtube.com/watch?v=SuUVSeCcJuM&list=PLKUs0nZcq-0gSX5EkXmSUIlSACskibVo1&index=15 that mentions the usage of publicationoutputmetadatafile during publishing. Worth the watch.
    • OutputFormats can be set inactive. The active/inactive flag in general indicates that it is still a valid for all content in the repository. It just means that any enduser assists screens will no longer actively show the entry. Quite handy to remove of OutputFormat with before-aquisition company names for example.

    -Dave
    emoji
Reply
  • 0

    Hi Kendall,

    Good question, and I would love to read some other best practices that people came up with over time. So sharing some thoughts...

    The essence of OutputFormats is to hide the technical complexity and implementation details. For example the "Red Cover Letter-size PDF"; how the PDF is generated and which version of DITA-OT, stylesheets, resolutions required or anything else does not matter for most of the end users.

    Combining an OutputFormat with content like language(s), baselines, resources, etc - it becomes a PublicationOutput. My content in the required language in the "Red Cover Letter-size PDF" layout.

    That PublicationOutput is the most readable/simple entry for many end users on what it is about. You mention of which there can only be one, however I've seen customers that add parameters on the PublicationOutput (so publication language level) that changes the purpose/layout/target of the OutputFormat. In that sense the OutputFormat name is no longer the simple summary so things like with/without labels or TOC - the end user has to look at the metadata if this was published with labels or not. Typically there examples with or without metadata boxes or with or without draft-comments.

    Indeed, if you want all 6 to be controlled, then you need 6 PublicationOutput entries. If you can live with OutputFormat "Output to staging" with a metadata flag on PublicationOutput to tune the publish on what to do, you end up with 3.

    For other forum members I would like to add

    • A half hour somewhat technical introduction on publishing is on TXS 2020 Day 2: Integrating New Publishing Outputs SDL Tridion Docs - YouTube https://www.youtube.com/watch?v=SuUVSeCcJuM&list=PLKUs0nZcq-0gSX5EkXmSUIlSACskibVo1&index=15 that mentions the usage of publicationoutputmetadatafile during publishing. Worth the watch.
    • OutputFormats can be set inactive. The active/inactive flag in general indicates that it is still a valid for all content in the repository. It just means that any enduser assists screens will no longer actively show the entry. Quite handy to remove of OutputFormat with before-aquisition company names for example.

    -Dave
    emoji
Children