 |
 |
I have to take any valid METS; I'm supposed to cache every possible .xsd and have directions for all my contributors to cache every possible .xsd file? I don't know what version of MIX, MODS, PREMISE, ALTO they are going to use from week to week. You can only specify one schema at a time with --schema in xmllint. This weekend, if it is still down, I'll create an XML catalog file of all loc xsd along with all the loc xsd and put it up on github. Long term, I think LOC has demonstrated it is not a reliable partner, and this class of international standards might need a host that is immune from petty domestic US politics. Sent from my iPad > On Oct 3, 2013, at 7:32 AM, "Jon Stroop" <[log in to unmask]> wrote: > > A few things (not directed toward anyone in particular, but in general I'm having a hard time believing this is an issue): > > 1. A single point of failure is never a good idea, right? In linked-data land this is a bigger question. In XSD land the solution seems pretty simple to me-cache it! > > 2 When we're all validating each of our 500 gazillion METS are we really hitting loc.gov each and every time, for every record? Hopefully not, so chances are there is a cached copy somewhere. Maybe this is an opportunity to learn where the various tools we all use keep that copy? > > 3. It's possible to validate an XML document against a different schema than the one it references. On the command line with xmllint > > $ xmllint --schema mets.xsd 2397415.mets --noout > 2397415.mets validates > > Catalogs might be a solution, but you could also just change any import statements to point to local copies of those schemas. Kevin Clark listed a few other libraries, any of which could do this. > > 4. I don't think it's part of [anyone conspiring to shutdown the federal government]'s agenda to delete </div> tags across the worlds IRs. Chances are your structMaps are going to be OK while loc.gov is unavailable. > > -Jon