Using prodname metadata in DITA?

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

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

It seems that prodinfo itself is intended to indicate its applicability to a particular product, and you can have more than one to indicate that it is applicable to several products.

But then inside prodinfo you have a component, brand, series, etc. that seem to me to be universal metadata - i.e. metadata that says the topic applies to a wider range of topics. But this does not make sense if it is inside a specific prodinfo element. For example, if I interpret a component to indicate that a topic refers to a specific component of a product, say, an engine, then this can be used to search for topics that can be reused for several different products, all of which describe the engine component in a similar way.

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 think that component metadata should not be tied to a specific product in this case. So how are these parts intended for use in DITA metadata?

+4
source share
3 answers

We use prodname in our map files to determine the PDF template that will be used in our conversion scripts. Each product has its own appearance, and the prodname value determines which format to use. And we use brand, series, etc. (Also indicated in the map file) as values ​​for creating the first page of the PDF.

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

+1
source

For our purposes, only the prodinfo method for describing product metadata works. Our situation is this: we have a software product (server application), which is sold under our own brand, as well as in OEM models with different brands.

So what do we do then:

 <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 mark the topics as related to one OEM partner, as well as filter on the product name itself (since the supplied solutions for OEM partners usually consist of a combination of products).

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

+3
source

The thought of this issue will be to rely on a map to determine metadata for a specific context. You can then use @conkeyref in the subject to pull it off the map so that the correct information for the correct structure that you describe at that point is generated on the output. Thus, you do not have several elements within the same topic to show the applicability of the topic.

In the keydef map, you can even create all the associated metadata and filter out keys that are not applicable, so the correct metadata will be applied to this topic.

+3
source

All Articles