Suggested schema changeRemove address wrapper element to simplify location element.
Problem this suggestion addressesThe location element is a wrapper element that contains another wrapper element, address, which in turn contains electronic and physical addresses.
The address element conveys no semantic information, but serves only to lengthen XML paths. It also complicates decisions about feed structures, as a decision needs to be made about the level at which to repeat elements, but the decision has no meaning, see example below:
location
address
electronic 1
electronic 2
or
location
RIF-CS schema components affected Address element and all child elements
Impact on content providersAll harvest feeds containing the address element.
ProsSimplifies schema and its use
ConsWorkload for metadata providers.
Technical options To remove the address wrapper element the rif-cs schema definition of location type will need to be changed from its current form to
<xsd:complexType name="locationType">
<xsd:annotation>
<xsd:documentation> The location element can hold physical and/or electronic addresses as well as geographical references. An electronic address could be a website containing details about the activity or email address whereas physical addresses can be provided for snail mail, billing, enquiries. Physical addresses are split into parts should a more granular division of address be required.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="electronic" type="electronicAddressType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="physical" type="physicalAddressType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="spatial" type="spatialType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="dateRangeAttributes"/>
<xsd:attribute name="type" use="optional" type="xsd:string">
<xsd:annotation>
<xsd:documentation>This attribute is not currently used</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
Implications:
The change would require database changes to both tables and functions. The harvester api would need to be changed as well as the ORCA data import and export functions.
The content providers guide would need to be updated. More helpful information to content providers on best practice for nesting elements is required.
Though it is technically possible to change the type of the location element by removing the address element, the lack of backward compatibility with existing records would mean an enormous amount of work within the ORCA system and for content providers.