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