Stable schema locations

Rod Widdowson rdw at steadingsoftware.com
Tue Feb 4 04:28:33 EST 2014


> So the very idea of a deployer
> using versioned schema references to "lock" the grammar to a particular
> release would introduce an undesirable behavior.

Plus the maintenance load of documenting and then saying "to use this
feature you need to change this impenetrable header at the top of
attribute-resolver" makes that infeasible.

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

It feels like this is the 'least worst' solution. I'd like to suggest a
couple of additions however

- Might it be possible (for the sake of documentation) to add rewrites to
tagged versions for each release.  So for instance:

http://shibboleth.net/schema/idp/resolver/V3.0.1/shibboleth-2.0-attribute-re
solver.xsd

Could point to whatever was tagged for that release.  That helps in the
(rarely, if ever occurring) case where people are trying to use new stuff
which we introduce with a down level release. And cannot work out why it has
failed.  Of course the odds of use revising the schema again have to be
disappearingly small, but you never know.

- That we make a mental note to ensure that our legacy classpath: urls
continue to work - for backwards compatibility with the installed base.
Right now they will, but if we take it into our heads to move the schema
location in the jar badness will occur - but only for legacy installs.

/rod



More information about the dev mailing list