migrating xml schema definitions from v2 to v3 ?

Brent Putman putmanb at georgetown.edu
Thu Feb 28 15:01:56 EST 2013


On 2/28/13 2:50 PM, Cantor, Scott wrote:
> On 2/28/13 2:47 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>> So, Resource.java lives in utilities/java-support so it can be used by
>> the idp as well as opensaml (for the metadata provider abstraction),
>> but the xml schema definitions to configure the resource
>> implementations need to be only visible by the idp and not opensaml,
>> correct ?
> They have to be visible at runtime, but that's done by making sure the
> parser when it's operating can find and load the IdP schemas. They don't
> ever have to be physically inside the OpenSAML code or shipped with it.


I wasn't sure if you were talking about just our custom config schemas
(so shib-common and IdP stuff) or *all* XML schemas period.  If the
latter, there is certainly code currently in OpenSAML that supports
schema validation of SAML documents, and for building the JAXP (?)
Schema instances to do so.  Those therefore have dependencies to the
SAML schemas, and the schemas currently live in the relevant jar
file(s).  I think they're probably just pulled in as classpath
resources, I'd have to check.  If so, then I suppose they don't *have*
to live in the same jar as the code.  But...

Not sure what I think yet about having dedicated co-located jars or
whatever for schemas.  If the primary reason for co-location is
documentation, I'd say that a common jar doesn't really solve it.  I'm
(at the moment, subject to change) inclined to say:

- an "operational" copy of each schema should live in the jar file that
is "closest" to the relevant code, which is pretty much as it is today

- a "documentation" copy of all the schemas could perhaps live not in a
jar, but in a single directory shipped with the IdP.  The goal being
accessibility and visibility.  Possibly implemented in the
build/packaging process by just extracting from all the jars (e.g. all
resources that match "/schemas/*").  Perhaps a Maven assembly task,
similar to some of the other things we do in assemblies today.



More information about the dev mailing list