Documentation Center

Metadata Setup Structures Reference

All metadata setup scripts need to share a number of characteristics. First of all, they need to be compatible with a schema.

Content Manager uses card types to define a number of objects types for its core business logic. Those should not be created, updated or deleted. It is however possible to add or remove fields to or from card types, or to change LOV and LOV values for the fields.

After you have analyzed the existing fields, card types and LOVs in the database, and defined what you will change, you need to write a XML structure describing the new elements. That structure will be used by DBUT for performing the changes. Note that after using DBUT, the ASP pages that generate the user interface must still be manually updated.

Here are the main characteristics of this XML structure:
  • Compatible with the schema you can find here: C:\InfoShare\App\Database\InfoShareCM\XmlSetup.xsd. If it doesn't, DBUT will return errors that will have to be corrected before the change can be effective.
  • The names you use for new fields, LOV or LOV values conform to the naming convention.
Naming convention

When declaring customer specific metadata, you need to provide a unique identifier for the object that you declare: the element name. The element name will then be used when coding Content Manager Active Server Pages (ASPs) and in Web Services API calls.

  • The following characters are allowed:
    • Digits from 0 to 9
    • Letters from A to Z
    • A point (.)
    • A hyphen (-)
  • The element name should be in uppercase.
The following naming convention should be respected:
TypeMaximum lengthNamingExample
List of Values (LOV)100 characters"D" + [NAMEOFLIST]DSTATUS
Values inside an LOV100 characters"V" + [NAMEOFLIST] + [NAMEOFELEMENT]VSTATUSRELEASED
Content Manager-specific field30 characters"FISH" + [NAMEOFFIELD]FISHDESCRIPTION
Customer-specific field30 characters"F" + [NAMEOFFIELD]FVALIDATEDBY
Card types
A card type defines the behavior of objects in Content Manager. Card types themselves cannot be created nor removed from the database, but an existing card type can be extended with customer-defined fields.
Card typesInternal card type name
Image - LogicalCTIMG
Image - VersionCTIMGV
Image - LanguageCTIMGL
Library Topic - LogicalCTLIB
Library Topic - VersionCTLIBV
Library Topic - LanguageCTLIBL
Map - LogicalCTMASTER
Map - VersionCTMASTERV
Map - LanguageCTMASTERL
Topic - LogicalCTMAP
Topic - VersionCTMAPV
Topic - LanguageCTMAPL
Publication - LogicalCTPUBLICATION
Publication - VersionCTPUBLICATIONV
Publication - OutputCTPUBLICATIONOUTPUT
Output formatCTOUTPUTFORMAT
Other (Word, PDF, ...) - LogicalCTTEMPLATE
Other (Word, PDF, ...) - VersionCTTEMPLATEV
Other (Word, PDF, ...) - LanguageCTTEMPLATEL
Translation jobCTTRANSJOB
Configuration settingsCTCONFIGURATION

When you add a mandatory field to a card type, you must specify a default value.

A default value is only set when linking a field to a card type. This default value is set on all existing instances of this card type. For all newly created instances you must specify an allowed value for the field in the user interface.