Page Comparison

...

1. Instance Schema
   1. Paired Values/Sequencing
      1. Issue: Does existing Schema account for "paired fields" sufficiently, for examples such as Marc 583 $n$o via <linkage> and <fieldLinkAndSequenceNumber> that are commented out?  COMMENTS:  data storage as data attributes is a.o.k, as long as presentation is based on functional requirements. Linkage that has been commented out and must be restored and then restored.
      2.  Should display/edit of Call Numbers- parsed to 4 elements, be modified in how it is stored?
         1. Users need to copy the entire call number and copy and paste - do not want to copy a piece of the call number to specific fields. prefix and suffix very local - should not be copied from OCLC - we need to determine if we can split the call number from item (classification/item) is there a real business case to split these at the database layer (classification team may determine the real need for this) Mechael: Use Cases - Patty/Dev Team - options; Jeff: easier to keep separate - we can combine when needed (storage)
      3. Proposed Solution Discussed:
      4. Refactor Cost:
   2. Legacy Data
      1. Issue: is this about complexity of mapping old data to new structure? 
         1. challenge - pulling from mark holding to the instance record for legacy data- ; User Interface is challenging for the amount of data that needs to be entered for instance vs. holdings.
      2. And how/where to account for "extension elements"?
      3. Proposed Solution Discussed:
      4. Refactor Cost:
   3. MFHD mappings
      1. Issue: is this same as above or more about renaming and reordering of key elements that occurred in OLE instance, Instance-to-MFHD (brief)
      2. Proposed Solution Discussed:
      3. Refactor Cost:
   4. Omitted/missing data elements
      1. Issue: Values not yet included in 9.x schema – need approach for adding/extending vs what is stored in linked transactional --number of circulations, Donor public display; donor note; price (why needed?); number of pieces (calc); checkin note (or does this stay in tx); other notes. How to use <institutionToWhichFieldApplies> .
      2. Proposed Solution Discussed:
      3. Refactor Cost:
   5. Configuring "extension" elements (for UI, indexing)
      1. Issue: Need to determine approach and future support for adding local "extension elements" provided for in schema at Instance, Holding, and Item levels- need functional and technical scope for 1.0 (what do libraries need, esp if not all MFHD fields provided in initial xml? How extensible and editable will our indexing, Search logic, Search UIs, Editor UIs need to be for early adopters?)
      2. Proposed Solution Discussed:
      3. Refactor Cost:
   6. Location elements- in Items, Hierarchy
      1. Issue: Variation of opinions on use of Temporary, Permanent as Location statuses, instead of repeatable elements named separately; Locations stored in provided 5 level hierarchy (OLE coding 5, but only have 2 levels in sample data, and NCSU wants X levels); location of Location elements at Item level.
      2. Proposed Solution Discussed:
      3. Refactor Cost:
2. Bib-Instance
   1. Item linkages
      1. Issue: what/how is OLE using unique identifiers to support NCIP, Discovery layer-Bib Numbers in OLE-Email thread
      2. Proposed Solution Discussed:
      3. Refactor Cost:

...