How to use customer specific profiles

[MartinKoeditz]

I'm using DAPS for creating customer specific book sets. I tried using the profile switch to show / hide specific sections, but that doesn't work. Each section is visible.

What is the correct process for my purpose?

[ghost]

Hi Martin,

you generally need three parts for this to work:

1. Your DC files (or alternatively, your command line) needs profiling via a PROF... line, e.g. for a document for Example Corp. and Yoyo Inc, you could use PROFVENDOR=examplecorp; yoyoinc.

2. Your MAIN file needs the following xml-stylesheet PI at the top, directly after <?xml version="1.0"?>:

   <?xml-stylesheet href="urn:x-suse:xslt:profiling:docbook51-profile.xsl"
     type="text/xml" title="Profiling step"?>
   

   Depending the DocBook version you are using, you may have to choose a different profiling stylesheet to apply.
   In case your catalog does not provide this URN, you can probably just use an absolute file path, like href="/usr/share/daps/daps-xslt/profiling/docbook51-profile.xsl".

3. You need profiled content matching the profiling in your DC file <phrase vendor="yoyoinc">Hello friends at Yoyo Inc</phrase>

[MartinKoeditz]

Hi Stefan,

how can I add the profile on the command line when using the -m switch? Currently I use:

daps -vv -m "xml/SynDesk-docs05.xml" --styleroot "/usr/share/xml/docbook/stylesheet/synergy2015-ns" html

[MartinKoeditz]

OK, too simpel:

daps -vv -m "xml/SynDesk-docs05.xml" --styleroot "/usr/share/xml/docbook/stylesheet/synergy2015-ns" html PROFVENDOR=examplecorp

[fsundermeyer]

Yep, this works with all profiling variables. Note, however, that almost all of the other config variables will not work that way. I am resetting them at the start to avoid unwanted settings from variables that have accidentally been set (not sure whether this is usual practice, however).
If you run into such a case, use a DC-file (or file a bug for me to remove resetting the variables ;-D if DC-files are not an option for you)

[fsundermeyer]

Hi,

in addition to what Stefan already provided:

You can have a look at the SUSE Linux Enterprise documentation repository for examples. We are usinng profilng (PROFOS, os="") to generate different versions of our Installation Quick Start:

• DC-file for the SLED variant: https://github.com/SUSE/doc-sle/blob/main/DC-SLED-installquick
• DC-file for the SLES variant: https://github.com/SUSE/doc-sle/blob/main/DC-SLES-installquick
• XML file: https://github.com/SUSE/doc-sle/blob/main/xml/art_sle_install_quick.xml

The SLED DC file has PROFOS=sled, meaning that for this variant all XML parts that have the os="" not set to sledwill get _excluded:

• os="sled" => included
• os="sled;foo:bar" => included
• os="foo" => excluded
• os="foo,bar" => excluded

It works the same for the SLES variant with PROFOS="sles" and os="sles".

If you have more than two variants, you can combine values in a ";"-seperated list: `os="sles;sled" to show parts for two variants but not a potential third.

Same goes for the value in the DC files. If you have three variants of a product "basic", "enhanced", "full" and where "enhanced" contaiins the funcionality of "base" and full the functionality of "base" and "enhanced", you need to do the following (using the role="" attribute)

• DC-base: PROFROLE="basic"
• DC-enhanced: PROFROLE="basic;enhanced"
• DC-full: PROFROLE="basic;enhanced;full"

XML:

<lisitem role="basic">
  <para>Feature basic</para>
</listitem>
<lisitem role="enhanced">
  <para>Feature enhanced</para>
</listitem>
<lisitem role="full">
  <para>Feature full</para>
</listitem>
<lisitem role="basic;full">
  <para>Feature basic & full onll</para>
</listitem>

You can use profiling directly with all block elements or online with <phrase>. The XML that results after the profiling needs to be valid, of course.

For more information incl. a list of valid profiling attributes, have a look at the DAPS documentation at https://opensuse.github.io/daps/doc/cha.daps.user.modular.html#sec.daps.user.modular.profile