Stable schema locations

[Cantor, Scott]

On 2/3/14, 11:43 AM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>Okay, noting that I do not know how to do the rewrite.

I put one together for now, the main issue is versioning. We treat
configuration schemas as more an artifact of software releases than
independently versioned objects themselves, so the version is really over
a "set" of schemas.

But the problem is that we're really trying to serve two goals at the same
time, facilitating editors and making Spring work the way it wants to. The
latter goal is problematic because spring.schemas maps locations and not
namespaces. We probably don't want to *have* to change spring.schemas
between releases, so we can't have it carrying URLs that include
versioning.

There's a second consideration, which is that if a deployer ever pointed
schemaLocation at a URL that wasn't in spring.schemas, Spring would
remotely fetch that schema at runtime. So the very idea of a deployer
using versioned schema references to "lock" the grammar to a particular
release would introduce an undesirable behavior.

For now, I followed that logic to the conclusion that versioned URLs
shouldn't be included. So I mapped URLs like:

http://shibboleth.net/schema/idp/resolver/shibboleth-2.0-attribute-resolver
.xsd


The "resolver" token identifies the module where the schema lives. I also
have filter and rp defined for now, but we might change rp to profile
based on the module name we're using.

There are other possible conclusions, the main ones I see being:

- dump spring.schemas and implement our own Spring plugins to override
their behavior (the original plan)
- maintain spring.schemas with version-specific mappings between releases

>I think we should prefer the Nexus public repository for the "real"
>location.

I did the redirects server side using mod_proxy (this is fairly automatic
with mod_rewrite) to save lag time and hide the real locations from any
editors out there that might cache the redirect result. So I could change
them, but right now I prefer svn to Nexus because it's much simpler to
build links, and it's faster.

-- Scott