4

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?

Anders
  • 12,556
  • 24
  • 104
  • 151

3 Answers3

3

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 :-)

David Heijl
  • 399
  • 2
  • 5
  • Ok, slightly different situation. What I'm referring to is metadata that can be used for retrieval of reusable content, not filtering. So basically, a topic can be about a diesel engine, e.g., currently used for one product, and it is potentially reusable, so another user might want to search for topics about the diesel engine. But that metadata should then not be tied in to a specific product metadata (as it is in prodinfo). – Anders Feb 28 '13 at 16:47
  • I see. I may be wrong, but could you not add second prodinfo to the diesel engine topic, to indicate that it is valid both for the diesel engine of truck A (with version X, brand Y, ...) as well as for truck B (with version Z, brand Y, ...)? – David Heijl Mar 01 '13 at 11:27
  • Well, I thought of that, but that's the very gist of the problem - it seems counter-intuitive and repetitive: if the prodinfo is for unique products, while the component metadata is to be generic ("diesel engine" as in reusable material), then it doesn't make sense to repeat that metadata inside each prodinfo. For many topics it doesn't even make sense to use prodinfo at all, if they are very reusable topics, and then component wouldn't even be available. – Anders Mar 01 '13 at 14:03
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.

JulioV
  • 516
  • 2
  • 3
  • Interesting points, but not really what I'm after, I'm afraid. I forgot to mention that I'm talking about usage in a CMS, and one without conkeyref or keyref support, since DITA 1.2 is not supported yet. Also, what I'm questioning is the prodinfo element's usefulness in a topic context for retrieval, and especially the component sub element. And if it's used for retrieval then getting it from the map would not be possible. But maybe that is the problem - the prodinfo is available for both ditamaps and topics, whereas they make sense in ditamaps, but perhaps not in topics... – Anders Mar 08 '13 at 15:17
  • Although not the answer I'm after, I'll award you the bounty for the interesting ideas, as the bounty will expire if I wait for the answer I'm after :-) – Anders Mar 13 '13 at 06:52
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.

Nathalie Laroche
  • 190
  • 1
  • 5
  • 1
    I agree, this usage makes sense, and in that respect I don't have so much of a problem with the prodinfo, although I still don't see what the component sub element would be meant for in that context. The problem is more about it's usefulness in topics. The original situation was we wanted a metadata element for component, and found it in prodinfo. But that didn't make sense to us, since we considered component a type of metadata to tag something with irrespective of what product that particular component belonged to... – Anders Mar 08 '13 at 15:20
  • 1
    Nathalie, your answer may not exactly be the answer to my question, but it points to the direction I commented on in my first comment - that prodinfo is mostly suitable as ditamap metadata, and that there may be problems in the structure of it (as with the component metadata) that are inherent in the model itself. For lack of evidence against this, I'll consider that my interpretation of your answer :-) and mark it as answered. – Anders Mar 13 '13 at 06:59
  • I'm still relatively new to DITA, so I don't feel confident enough about it to be able to fully answer questions and debate issues. Yet. :) But I wanted to share how we use the prodinfo in our maps, and I'm glad it helped somewhat. – Nathalie Laroche Mar 13 '13 at 13:36