Use of prodname metadata in DITA?

Question

What is the intended usage of the metadata elements inside the prodinfo element in the DITA metadata?

Each prodinfo (can be multiple) has only one prodname, and then inside you can have component, brand, series, etc.

The prodinfo itself seems to be intended to indicate its applicability to a specific product, and you can have more than one to indicate that its applicable to multiple products.

But then inside the prodinfo you have component, brand, series, etc, which to me seems like generic metadata - i.e. metadata that says the topic is applicable to a broader spectrum of topics. But it doesn't make sense if it's inside the specific prodinfo element. For instance, if I interpret component to indicate that the topic concerns a particular component of a product, say the engine, then that might be used to find topics that could be reused for several different products, all describing the engine component similarly.

Example:

    <metadata>
        <prodinfo>
            <prodname>SuperMachine</prodname>
            <vrmlist>
                <vrm version="1.0"/>
            </vrmlist>
            <component>power pack</component>
            <component>engine</component>
            <brand>ACME</brand>
            <series>Z32</series>
        </prodinfo>
    </metadata>

I would think that the component metadata should be non-attached to a specific product in this case. So how are these parts intended to be used in the DITA metadata?

Answer 1

We use the prodname in our map files to determine the PDF template to use in our transformation scenarios. Each product has its own look and feel, and the prodname value determines which format to use. And we use the brand, series, etc., (also specified in the map file) as values to generate the first page of the PDF.

Not sure if this is the best approach, but it works quite well for us.

Answer 2

For our purposes, the prodinfo way of describing product metadata just works. Our situation is the following: we have a software product (a server application) that is sold under our own brand name, but also in an OEM model with different brands.

So what we then do is this:

<metadata>
    <prodinfo>
        <prodname>OurBigServerSoftware</prodname>
        <vrmlist>
            <vrm version="10"/>
        </vrmlist>
        <component>PDF rendering engine</component>
        <brand>OEM Partner 1</brand>
    </prodinfo>
</metadata>

This allows us to tag topics as being specific to a single OEM partner, but also to filter on the product name itself (since the bundled solutions for the OEM partners usually consist of a combination of products).

I guess that is just way of saying that there is a scenario where it does make sense :-)

Answer 3

A thought about this question would be to rely on the map to define the metadata for the particular context. You can then use @conkeyref in the topic to pull in the from the map so that the correct information for the correct structure you're describing at that point is generated in the output. This way you don't have multiple elements within a single topic to show the applicability of the topic.

In a keydef map, you could even create all of the associated metadata required and filter out the keys that don't apply so the right metadata gets applied to the topic.