Print

Print


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
------------------------------------