> From: Metadata Object Description Schema List [mailto:[log in to unmask]] On Behalf Of Rick Beaubien
> Sent: Friday, March 13, 2009 8:28 PM
> To: [log in to unmask]
> Subject: Re: [MODS] URL for the current version of mods
> Actually, there is not, to my knowledge, a one-to-one relationship between target namespaces and
> schemas.  For example, versions 3.0 through version 3.3 of MODS all declare the same target 
> namespace:  But each is represented by a different schema (or version of the 
> mods schema).

My statement about a one-to-one relationship was a bit strong however, the situation you describe is a special case with the caveat that there are *no* breaking changes between the different versions of the schema, e.g., optional and default attributes are allowable and optional elements placed at the end of a "sequence" or in an existing "choice" or "any" are allowable.  Otherwise you would have a breaking change which would warrant a new namespace since client applications wouldn't be able to validate the XML instance documents due to the conflicting schemas.

> The case is even more complex for xlink, for which there is no normative schema--users have been left to 
> role their own implementations of xlink.

Yes, but the XLink specification does define a schema and client behaviors based on that schema.  It would have been nice to have a normative XML schema for it, but its really not that hard to create one, if one doesn't already exist on the W3C site.

> But as far as I know, all implementations of xlink are supposed 
> to be declaring the same target namespace regardless of the particular implementation of xlink they 
> reference.  Initially the MODS and METS schemas imported different xlink schemas, although each was 
> identified by the same target namespace.

The XLink specification specifies the namespace that implementation are suppose to use.  If you don't use that namespace, then you don't conform to the XLink specification.  In the case of early MODS and METS, they defined their own namespace that had nothing to do with the XLink specification, but used similarly named attributes and semantics to XLink.  I belive that was why people requested that the proper namespace be used and why it was changed accordingly.