Where to host OLAC schemas

[Steven Bird]

Recently there was some discussion about hosting the schemas for certain
OLAC vocabularies off-site at a location that is directly managed by the
author of the schema, mainly because this would be more convenient for the
author.

After some consideration, Gary and I now believe that these documents
should be hosted on the OLAC site.  Here are several reasons why:

1. Only mature vocabularies achieve community-wide acceptance, and we
anticipate a slow rate of change by the time a vocabulary is approved at
the OLAC level.  Therefore the updates to the schema will be infrequent.
The process of installing a revised schema on the OLAC site would involve a
second level of quality control, and this is appropriate for an OLAC
tandard that many other systems depend on.

2. Any recommendations and implementation notes pertaining to the
vocabulary will already be posted on the OLAC site.  New versions of these
documents may need to be created when a vocabulary is updated.
Transferring an updated schema to the OLAC site does not represent a
significant additional burden.

3. When several sites host official OLAC schemas, only one of the sites has
to be down in order for validation to be impossible.

4. People can see that a schema is endorsed by OLAC simply from its
location, rather than having to inspect the XML schema for the OLAC
metadata format.  If OLAC vocabularies are ever adopted into other DCMI
application profiles then the link to OLAC is maintained.

5. We draw a clear division between OLAC extensions and third-party
extensions, when schemas that are approved by the community are put in the
OLAC namespace and hosted on the OLAC site.

6. Posting material from many authors on the OLAC site demonstrates that
building OLAC is a community effort.  Additionally, authors of OLAC
vocabularies and the associated schemas are able to demonstrate the impact
of their work when they can point to their documents posted on the OLAC
site.

Convinced?  Please let us know what you think.

Thanks,
Steven Bird