This page is a subpage of CMDI 1.2

Mandatory MdProfile header element

The issue

In CMDI 1.1, all header elements are optional including MdProfile. Because of this, and the fact that the xsi:schemaLocation attribute cannot be made mandatory either, it is possible to create schema valid CMDI instances that do not link back to the profile they are based on.

Proposed solution

Make /CMD/Header/MdProfile a mandatory element path in all CMDI instance (through the new version of the comp2schema-header XSD).

Pros

With this solution, it is guaranteed that all valid metadata instances have the ID of their profile specified.

Cons

• the correctness of the referenced profile (i.e. the value of MdProfile actually identifying the profile the instance was based on) is not enforced (this could be done through the schema but may be overly restrictive)
• upgrading from 1.1 instances without a MdProfile header item may be complicated or in some (theoretical) cases impossible because the information is simply not available (which is the issue being addressed here!). Possibly a dummy 'unknown' profile ID could be inserted in those cases if there are any.

Centre impact

Aside from the general conversion, generation scripts may need to be updated.

Implementation examples

comp2schema-header:

            <xsl:template name="PrintHeader">
        
                <xs:element name="Header" minOccurs="1">
                    <xs:complexType>
                        <xs:sequence>
                            ...
                            <xs:element name="MdProfile" type="xs:anyURI" minOccurs="1"/>
                            ...
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>

Tickets

Tickets in the CMDI 1.2 milestone with the keyword mdprofile:

Ticket	Summary	Owner	Component	Priority	Status
#403	Make MdProfile mandatory	Dieter Van Uytvanck	ComponentSchema	major	closed

Discussion

Axel?: I would strongly oppose an 'unknown' value for missing profile IDs on upgrade. We couldn't prevent people from misusing this option in native 1.2 profiles. Conceptually, introducing 'unknown' makes (the value of) MdProfile optional again. As you say, it would only serve a (hypothetical?) border case where nobody feels responsible for a given set of MD instances anyway.

Twan?: I agree, the costs do not seem to outweigh the benefits

Menzo?: We can let the conversion XSLT terminate and require curation.

Oliver?: I also agree with Twan and Axel. Allowing a value of 'unknown' essentially makes MdProfile optional again, we don't want this. Centers need to fix their data during curation.