Suggested schema change
Remove address wrapper element to simplify location element.

Problem this suggestion addresses
The 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

address

electronic 1
address

electronic 2

RIF-CS schema components affected
Address element and all child elements

Impact on content providers
All harvest feeds containing the address element.

Pros
Simplifies schema and its use

Cons
Workload 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.