I've been thinking about a little problem to do with our Fez XSDs mappings in Fez. In a nutshell, we need a way of copying XSD mappings between different Fez instances.

The first iteration of this was to make an XSD exporter which reads the XSD mapping database and exports the structure to an XML file.

However, the complication is how to merge conflicts when importing XSDs? And also how to know what is in the new XSD XML files?

Part of the complication is that each XSD Display Mapping has an xdis_id which is stored in the record to tell Fez which content model to use to handle the record. But what if a Fez user 'out there' creates a new XSD Display and uses an xdis_id that we have used here at UQ? When they get our Fez upgrade, they will no doubt want to upgrade to the new UQ XSDs but not want to lose the ones they've made. So I've made the Fez XSD importer try to detect when the new XSD doesn't match the existing one and save the new one to a new slot.

However, this collision detection is unhelpful in some ways. For example, what if the user has just changed the name of the XSD from english to spanish? The XSD importer will not upgrade their XSD because it will see a difference. How is the user supposed to get the updates? How are they to know what is in the updates? In many cases, XSD mappings need to be changed due to changes in the mapping API.

I've also had issues of users sending me exported XSDs that have used different xdis_ids for some of the core Displays like Generic MODS resulting in a mess of unresolved XSD Relationship links.

I had thought about reserving a block of xdis_ids for core Fez stuff and marking some XSDs as core Fez so that they will have a kind of 'brute force' power that makes them just overwrite whatever's there and always work. However, this still excludes the possibility of users being able to send each other XSDs that are safe from xdis_id conflicts.

I think the solution to this problem is to have namespaces for the xdis_ids. We could prefix ours with fez_core. Perhaps for our special UQ eSpace, we could use UQeSpace as the prefix. In the fedora records FezMD, we would store the xdis_id_prefix as well as the xdis_id. For records that are in the wild lacking the prefix, we could default to fez_core until the records are updated. I guess there might be performance issues having to query the xdis_id and the prefix every time but something along these lines is what I'm thinking.

This doesn't solve the problem of being able to compare old and new XSDs but takes us some of the way towards a sustainable solution.