Andrew, it sounds like you are saying that there shouldn't be a generic URL... ? I believe that people asked for it in the past, but maybe it's not a good idea. It seems to work when updates are backward compatible but not when they aren't. kc Houghton,Andrew wrote: >> From: Metadata Object Description Schema List [mailto:[log in to unmask]] On >> Behalf Of Rick Beaubien >> Sent: Thursday, March 12, 2009 5:02 PM >> To: [log in to unmask] >> Subject: [MODS] URL for the current version of mods >> >> The current version of MODS is available both through a version >> specific >> URL (http://www.loc.gov/standards/mods/v3/mods-3-3.xsd) as well as a >> more generic URL (http://www.loc.gov/standards/mods/mods.xsd). Can >> users count on the more generic URL always pointing to the most recent >> version of the MODS schema that is backwards compatible through version >> 3.1? (I believe that there is a break in compatibility between version >> 3.0 and 3.1). Or, to phrase the question a little differently, if a >> new >> version of the MODS schema was produced that was not backwards >> compatible with versions 3.1-3.3, would it replace the 3.3 schema that >> is now available via the generic URL >> http://www.loc.gov/standards/mods/mods.xsd? I am asking this because >> of >> its implications for how the schemaLocation in mods instances should be >> set up. >> > > What goes in xsi:schemaLocation is the namespace URI and a URI to the XML > schema for MODS. The namespace URI must match the targetNamespace attribute > in the XML schema for MODS which currently is: > > targetNamespace="http://www.loc.gov/mods/v3" > > for the XML schema URI you should be using the version specific URI in the > xsi:schemaLocation attribute of your XML instance document. Otherwise, as > your question suggests when version 4 of the MODS specification comes out > and it is not backward compatible, LC will have to change the target > namespace URI to something like: > > targetNamespace="http://www.loc.gov/mods/v4" > > anybody still using version 3 of MODS and who mistakenly used the generic > URI in their xsi:schemaLocation attribute of their XML instance documents > will now have a problem since the targetNamespace in the XML schema returned > from the generic URI will not match the namespace URI they used in the > xsi:schemaLocation attribute specified in their XML instance documents. If > the XML instance document is being read by an XML parser that is schema > aware, then the XML parser will throw an error, otherwise the application > processing the MODS instance document will not know there is a problem. The > generic XML schema URI should never be used in xsi:schemaLocation. > > Unfortunately, the LC web site doesn't make it clear which one you should be > using and when you dereference the generic URI you get back an HTTP 200 OK > status with the HTTP entity containing the latest version of the MODS schema. > What I believe the LC web site should be doing when dereferencing the generic > URI is to respond back with an HTTP 302 Found status and an HTTP Location > header containing the URI to the latest version of the MODS schema. Then it > would be obvious that you should be using the version specific URI instead > of the generic URI. > > > Andy. > > > -- ----------------------------------- Karen Coyle / Digital Library Consultant [log in to unmask] http://www.kcoyle.net ph.: 510-540-7596 skype: kcoylenet fx.: 510-848-3913 mo.: 510-435-8234 ------------------------------------