> We're trying to embed metadata files using the "1999" URI into METS
> documents with the "TR" URI.  If we don't change one or the other
> we'llhave to use two different namespace prefixes.  Not a terrible
> problem, but
> it would probably be easier to understand in ten years time if we
> had just
> one namespace for all XLink elements.

I was actually trying to help institutions
*avoid* having to use two different namespace
prefixes, although maybe I was thinking a bit
too far ahead.

My logic was as follows: the "1999" namespace
prefix specified in the current XLink recommendation
makes no sense *unless* you're planning on
enabling the distinction of XLink elements/attributes conforming with one
version of the recommendation from those
conforming to a later version.  If you
didn't want to draw that distinction, why
not use the 'version neutral' namespace
URI found in METS (and used for accessing
the most recent version of the XLink recommendation
at the W3C's web site)?  And if you really
want to make that distinction, then you
HAVE to use two namespaces within a particular
document instance (you may actually need
more than two, if you have XLink elements/
attributes from more than
two versions of the recommmendation).  So, if
you're going to have a document with Version 1
recommendation XLink elements and Version 1.1
Xlink elements and you want to distinguish
between them, you need something like this:
and xlmns:xlinkversion1.1=
These namespaces would then need to be linked
to appropriate schema for validation.

While the METS schema is only linked to one
XLink Schema, METS can support a wide range of embedded content, including XML files that might be
created using different versions of XLink.
Rather than force METS creators who are
embedding XML documents containing XLinks
within METS to either 1. bring all of their
XLinks into conformance with a particular
version of the recommmendation,
or 2. use multiple namespaces for different
XLink versions as above, I thought I would
use a 'generic' namespace which would allow
METS authors to drop XLink elements conforming
to different versions of the XLink recommendation
within a single METS instance and not have to
worry about implicit indications that the
XLinks are bound to a particular version/schema.
Of course, this means you do lose any insurance
of being able to validate XLink elements/attributes,
but gain the convenience of not having to hang
separate, slightly different namespaces on all
your XLinks.

So, the current situation appears to be that
in trying to avoid forcing people to deal
with two XLink namespaces in the future I've
made them deal with it now.  Obviously, this
is a suboptimal outcome.

I would be interested in others input on
this.  The XLink working group is dead, and
the chances that it will issue another version
any time soon are, essentially, zip.  So,
there's really no reason *not* to use the
official URI, one URI being as good as another,
and the odds of the W3C hanging a different
namespace URI on the xlink: namespace prefix
being slim.  On the other hand, if there's a
lot of installed base out there using the
"TR" namespace URI from METS, I wouldn't
want to force them all into a change when
it's easy enough for Harvard to modify
their copy of the METS schema to use a
"1999" namespace.  Thoughts?