...
- For OLE Instance elements that parallel MFHD fields/subfields - update <documentation> tags that were copied from the Library of Congress MFHD website: http://www.loc.gov/marc/holdings/.
- Remove references to MFHD fields and subfields and instead refer to related OLE instance elements.
- Make structural changes: e.g., change some global elements to complexTypes or imbed them within the holdings / item sections so there are only 2 root elements (<instance> and <instanceCollection>.
- Where needed, re-sequence and/or regroup elements to better match the parallel MFHD structure.
- Remove <enumeration values> for a variety of elements and designate the "type" as "codeOrIdentifier" so local implementers can choose data values from locally controlled "maintenance documents"/"code lists".
- Apply data lengths to some elements to better ensure that OLE Instance descriptions can be exported to the MFHD format as needed and stay within the character length limit of a MFHD record.[1|#_ftn1]
- Create separate schemas for individual modules of data to allow for easier updates and efficient maintainability, e.g., a separate schema for location that can be "included" within or "imported" to the OLE Instance schema.
- Determine usefulness of <linkage> and <fieldLinkAndSequenceNumber> and update schema appropriately.
- Determine usefulness of <alternateGraphicRepresentation> - if it is retained, will need to add a <linkage> subelement.
- Determine how to identify of "owners" of OLE Instance documents.
- Determine how to identify "circulation" locations.
- Final analysis and determination of status information – what types of statuses are needed – acquisitions, cataloging, circulation? How are the statuses generated? What should status data values be? Where should the status attributes be stored – the Docstore or OLE relational database management systems.
...